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Excerpts  from  the  1 989/90  UTCS  Annual  Plan 


This  issue  of  ComputerNews  incorporates  major  excerpts  from  the  1989/90  UTCS  Annual  Plan.  We  produce  a 
document  every  year  which  we  call  a  plan,  but  which  is  quite  a  bit  more.  It  contains  a  section  on  our  strategic 
directions,  an  annual  report  of  activities  and  projects  from  the  previous  year,  a  financial  summary  from  the  previous 
year,  financial  projections  for  the  new  year,  and  sections  on  various  areas  of  activity,  including  suggested  projects. 
We  use  our  plan  as  both  a  review  and  a  vehicle  to  suggest  specific  projects  which  are  consistent  with  our  strategic 
directions  and  with  the  evolution  of  computing  and  communications  on  campus.  Our  plan  is  used  to  lobby  for  funding 
for  projects,  and  this  year  we  have  been  successful  (subject  always  to  final  approval)  in  obtaining  approval  for  a 
number  of  networking  initiatives.  I  would  like  to  acknowledge  the  valuable  advice  and  feedback  we  receive  from  our 
Board  in  the  preparation  and  review  of  the  Plan  and  in  prioritizing  projects. 

Dr.  Warren  C.  Jackson,  Director 
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1.  INTRODUCTION 


The  1989/90  Annual  Plan  documents  the  continuing  ex¬ 
tension  of  the  three  backbone  communications  networks 
and  the  first  steps  in  their  integration.  Value  added 
services,  such  as  enhanced  connectivity  for  the  IBM 
domain,  are  beginning  to  be  offered.  We  are  becoming 
involved  in  a  number  of  network-based  services  which 
could,  in  total,  be  considered  the  start  of  a  global 
academic  information  system  or  data  base.  UTCS 
activities  in  a  number  of  external  networking  initiatives 
establish  a  central  role  for  the  University  in  Ontario  and 
national  networks,  as  well  as  in  connecting  to  other 
international  networks. 

The  central  academic  computing  services  UTCS  offers 
continue  to  evolve  toward  a  combination  of  an  IBM  VM 
system  and  increasingly  powerful  UNIX  systems. 

We  appear  to  be  finally  approaching  a  situation  where 
we  have  a  stable,  balanced  budget  for  most  basic 
functions.  Our  mandate  and  strategic  directions  have 
been  modified  to  reflect  our  continuing  evolution,  and  are 
listed  in  the  next  section. 


2.  STRATEGIC  DIRECTIONS 

We  have  regularly  presented  our  view  of  where  UTCS 
should  fit  in  the  University,  based  on  a  mandate  and  a 
set  of  strategic  directions  which  have  been  reviewed  and 
refined  regularly  over  the  past  four  annual  plans.  This 
year  we  feel  a  fairly  major  revision  is  in  order.  The  basic 
thrust  is  still  quite  robust,  but  changing  circumstances 
mean  that  they  need  to  be  regularly  monitored  and 
modified  for  relevance.  This  section  will  present  a 
modified  mandate  and  strategic  directions. 


2.1  Mandate  and  Basic  Operating  Principles 

The  mandate  of  UTCS  is  to  encourage  and  support  the 
use  of  information  technologies  across  campus,  to  plan, 
implement  and  operate  common-carrier  networks  and 
certain  appropriate  central  computer  facilities. 

In  carrying  out  this  mandate,  certain  basic  operating 
principles  must  be  observed: 


A.  The  focus  of  UTCS'  effort  will  be  on  the  planning, 
implementation,  support  and  integration  of 
systems  and  networks  based  on  existing  and 
emerging  academic  and/or  administrative  needs. 
UTCS’  activities  will  all  be  in  support  of  services 
which  are  explicitly  defined  in  terms  of  resources, 
results,  costs  and  the  source  of  funds  to  pay  for 
them. 

B.  Certain  of  UTCS’  services  will  be  centrally  funded 
or  subsidized;  the  rest  will  be  operated  on  a  partial 
or  full  cost-recovery  basis,  with  UTCS  having  the 
flexibility  to  introduce,  modify  or  discontinue  self¬ 
funding  services  as  it  deems  appropriate. 

C.  The  campus  backbone  network  will  continue  to  be 
designed  to  insulate  the  user-owned  local 
networks  which  it  connects  from  changes  in  back¬ 
bone  technology  and  protocols. 

D.  Facilities  will  be  provided  which  are  compatible 
with  vendor  independent  standards  whenever 
possible. 

2.2  Strategic  Directions 

In  accordance  with  this  mandate  and  subject  to  these 
operating  principles,  we  identify  a  few  strategic  directions 
against  which  our  activities,  expenditures  and  annual 
plans  should  be  tested.  These  directions  reflect  changes 
in  information  technologies,  user  attitudes,  and  the 
degree  of  decentralization  of  computing  decisions  seen 
on  our  campus. 

A.  UTCS  will  continue  to  expand  the  campus 
backbone  network  infrastructure,  planning  for  a 
single,  pervasive,  coherent,  integrated  networking 
environment  which  conforms  to  international 
standards. 

B.  UTCS  will  take  a  leading  role  in  encouraging  the 
development  of  high  bandwidth  external  networks 
which  allow  intimate  connections  to  other  campus 
networks  and  will  support,  operate,  and  implement 
institutional  external  network  connections. 
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C.  To  better  support  U  of  T  network  users,  UTCS  will 
continue  to  commit  resources  to  external  network 
connections  and  topologies  in  which  U  of  T  has  a 
central  hub  location. 

D.  In  support  of  networking  services,  UTCS  will  have 
to  maintain  at  least  one  integrated  computer/com¬ 
munications  environment. 

E.  UTCS  will  support  application  packages  that  allow 
users  flexibility  in  storing  and  processing  data  at 
the  most  efficient  place  on  the  campus  computer 
network. 

F.  Consulting,  planning,  implementation  and  man¬ 
agement  for  both  academic  and  local  administra¬ 
tive  systems  and  networks  will  continue  to  be  an 
important  area  of  UTCS  service. 

G.  A  major  thrust  of  UTCS  activities  will  continue  to 
be  to  provide  access  to,  and  advising  and  support 
services  for,  microcomputers  and  the  more  mod¬ 
est  examples  of  the  latest  technology  likely  to  be 
within  the  financial  reach  of  the  individual  re¬ 
searcher  or  small  department. 

H.  UTCS  will  continue  to  present  courses  to  the  Uni¬ 
versity  community  on  the  latest  developments  in 
information  technology  and  on  actual  useful  tech¬ 
niques  and  operational  packages.  UTCS  will 
collaborate  in  certain  areas  with  the  School  of 
Continuing  Studies  on  teaching  courses  exter¬ 
nally. 

I.  UTCS  will,  with  the  library,  coordinate,  support 
and  provide  general  university  public  access  to  in¬ 
creasing  amounts  of  academic  and  research- 
oriented  information  and  data  via  the  campus  and 
external  networks.  Common  user  interfaces  will  be 
provided  whenever  possible. 

J.  In  conjunction  with  the  organizations  that  develop 
central  administrative  and  registrarial  systems,  in¬ 
creased  access  to  administrative  and  registrarial 
data  will  be  available  via  the  network,  consistent 
with  security  and  integrity  requirements. 

K.  UTCS  will  continue  to  plan,  operate  and  support 
the  administrative  computing  facility. 


L.  A  number  of  facilities  are  likely  to  be  specifically, 
but  not  necessarily  uniquely,  provided  and 
supported  by  UTCS  because  of  their  high  cost  to 
divisional  units.  These  might  include  supercom¬ 
puting  services,  large-scale  data  storage  and 
staging,  high-quality  print  or  graphics  devices, 
fourth  generation  languages,  scanners,  some 
public  data  bases,  and  tape  storage  and  retrieval. 

These  directions  support  a  continuing  shift  away  from  the 
image  UTCS  has  had  of  being  primarily  an  operator  of 
large  machines  for  academic  services.  The  increased 
emphasis  on  microcomputer  hardware  and  software 
support  and  consulting,  facilities  management,  and 
networking  reflects  these  changes. 

3.  BASIC  ASSUMPTIONS 
AND  TIMING 

Our  plan  is  based  on  the  following  assumptions  and 
timing: 

3.1  The  Central  Administrative  Computer 

The  central  administrative  computer  was  upgraded  from 
an  IBM  4381  R03  to  an  R1 4  in  late  1987.  This  upgrade 
provided  approximately  25  to  35  percent  more  process¬ 
ing  power.  The  technical  subcommittee  of  the  Adminis¬ 
trative  Computing  Committee  is  recommending  an 
upgrade  in  capacity  based  on  processing  growth  figures 
of  25  to  40  percent  per  year  compounded.  We  assume 
that  funding  will  be  available  to  upgrade  the  system  to 
one  that  is  at  least  two  and  a  half  times  as  powerful 
during  Summer  1989. 


3.2  Academic  Computing  Services 

We  will  continue  to  treat  VM/CMS  as  the  preferred  UTCS 
delivery  vehicle  for  providing  academic  mainframe  com¬ 
puting  services.  We  assume  that  the  use  and  income  of 
our  IBM  VM  academic  service  has  stabilized,  and  that 
additional  uses  for  networking  and  the  data  archive  and 
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academic  information  data  base  will  mean  that  the  VM 
service  will  continue  in  operation  for  the  foreseeable 
future.  If  new  initiatives  and  services  based  on  VM  are 
successful,  the  present  machine,  an  IBM  4381  R02,  may 
have  to  be  replaced  with  one  of  greater  capacity  at  some 
point. 

3.3  UNIX  Services 

We  will  accommodate  time-sharing  UNIX  users  on  our 
upgraded  SUN  3/280.  The  new  SUN  3/280  we  added  in 
1988/89  will  be  used  primarily  for  networking. 

3.4  Communications  and  Network 
Services 

We  will  assume  again  this  year  that,  for  at  least  the  near 
term,  there  will  continue  to  be  a  heterogeneous  network¬ 
ing  environment  on  campus.  Steps  have  been  taken  and 
continue  to  bridge  the  three  major  (mostly  academic) 
backbone  networks  (General  Purpose  or  Ethernet- 
based;  terminal  switching  or  PACX-based;  IBM  token 
ring  backbone)  and  the  network  centered  on  the  IBM 
administrative  computer.  The  1989/90  plan  includes 
additional  connections.  By  the  end  of  the  1989/90  fiscal 
year,  nearly  universal  connectivity  for  and  between  users 
on  the  different  networks  should  be  available,  utilizing 
relatively  transparent  gateways  and  bridges  between  the 
networks. 

We  will  extend  the  backbone  network  and  required 
physical  infrastructure  as  funding  and  resources  permit. 
The  capabilities  of  the  backbone  will  be  upgraded  as  the 
technology  becomes  available  and  as  funding  permits. 

4.  1988/89  ANNUAL  REPORT 

4.1  Activity  Summary 

Throughout  1988,  UTCS  continued  to  be  active  in  net¬ 
working,  connecting  to  international  and  regional 
networks,  as  well  as  those  within  the  University. 


NSFnet  Connection 

In  May  1988,  UTCS  received  $30,000  of  base  funding  for 
a  56  Kbps  link  to  NSFnet,  via  Cornell  University  in  Ith¬ 
aca,  New  York.  This  was  insufficient  to  cover  all  the 
costs  of  this  link,  which  were  closer  to  $66,000  per  year. 

A  proposal  was  made  to  the  NetNorth  Executive  Commit¬ 
tee  to  physically  multiplex  a  19.2  Kbps  channel  from  the 
56  Kbps  and  use  it  to  connect  NetNorth  to  BITNET  for 
the  same  price  they  were  now  paying  for  a  9.6  Kbps  link 
from  Guelph.  The  proposal  was  accepted  and  another 
$20,000  of  the  cost  of  the  link  was  funded.  Some 
reconfiguration  of  east-  and  west-bound  NetNorth  links 
that  previously  went  to  Guelph  was  required  to  reflect  the 
emergence  of  Toronto  as  a  hub  and  minimize  the 
number  of  hops  for  distant  users  to  get  to  the  U.S.  The 
installation  of  the  link  to  Cornell  was  delayed  by  the 
summer  Bell  strike,  but  it  was  functional  by  October  14 
(at  least  that's  when  billing  started).  The  reconfiguration 
of  other  NetNorth  links  and  updates  to  affected  routing 
tables  will  take  until  February  to  complete. 

CSRI  was  finally  successful  in  installing  their  connection 
to  the  ARPAnet  via  a  direct  9.6  Kbps  channel  to  the 
University  of  Rochester.  UTCS’  connection  is  one  hop 
less  direct,  since  it  passes  through  Cornell  first,  but  is  of 
considerably  greater  bandwidth. 


ONet  (Ontario  Regional  Network) 

The  Ontario  regional  network,  now  called  ONet,  came 
into  being  when  the  computing  organizations  at  Toronto, 
Western,  McMaster,  Waterloo,  Queens,  and  York  univer¬ 
sities  decided  to  contribute  cisco  routers  and  share  the 
cost  of  9.6  Kbps  links  between  them.  The  Ontario  Centre 
for  Large  Scale  Computation  (OCLSC)  then  contributed 
the  cost  of  doubling  the  line  speed  to  19.2  Kbps,  at  least 
among  the  founding  members.  Two  Ontario  centres  of 
excellence,  ITRC  (Information  Technology  Research 
Centre)  and  ISTS  (Institute  of  Space  and  Terrestrial  Sci¬ 
ence)  have  since  joined.  In  the  new  year,  Guelph  will 
join.  A  56Kbps  line  to  Ottawa  will  be  installed  to  connect 
Carleton,  NRC,  BNR  and  potentially  other  Ottawa-based 
organizations.  ONet  provides  TCP/IP  connectivity 


ComputerNews  /  APRIL  1989  5 


between  the  networks  on  each  of  the  campuses. 

Though  the  routers  can  support  DECNET  traffic,  ad¬ 
dressing  concerns  make  this  less  straightforward.  While 
NetNorth  connects  these  and  many  other  campuses  al¬ 
ready,  NetNorth  is  a  batch-oriented,  store  and  forward 
network.  ONet  however,  allows  a  user  on  a  machine  on 
one  campus  to  interactively  log  onto  another  machine  on 
another  campus,  or  via  NSFnet  and  its  connections,  in 
the  U.S.  or  Europe.  Of  course,  the  user  must  have  an 
account  on  the  target  machine.  This  allows  an  unprece¬ 
dented  increase  in  the  productivity  of  interaction  with 
remote  hosts,  compared  to  NetNorth/BITNET.  As  more 
universities,  government  agencies,  and  centres  of  excel¬ 
lence  join  ONet,  the  additional  funds  will  be  used  to  add 


more  links,  as  appropriate,  and  to  increase  the  band¬ 
width  of  existing  ones.  Since  ONet  makes  use  of  the  U  of 
T  connection  to  NSFnet  at  Cornell,  $125,000  of  the  cost 
of  this  link  is  contributed  by  ONet. 


Proposed  NRCnet  National  Network 

For  some  time,  the  National  Research  Council  of 
Canada  (NRC)  has  been  exploring  the  possibility  of  es¬ 
tablishing  a  national,  high-speed  research  network 
across  Canada,  linking  regional  networks  of  universities, 
industrial  research  centres  and  government  agencies. 
UTCS  has  participated  in  many  of  the  meetings  investi- 
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gating  this  possibility.  This  past  summer,  NRC  hired  a 
consultant  to  prepare  a  “Request  For  Information”  (RFI) 
to  solicit  information  from  suppliers  or  consortia  of  suppli¬ 
ers,  to  install,  provide,  and  manage  such  a  network.  In 
December,  UTCS  in  partnership  with  IBM  and  CNCP  re¬ 
sponded  to  the  RFI  with  a  comprehensive  document  out¬ 
lining  several  bandwidth  scenarios.  Moreover,  UTCS 
offered  to  provide  the  Network  Operations  Centre  (NOC) 
function  for  the  whole  network,  as  well  as  software 
support  and  development  of  network  monitoring  and 
management  tools.  IBM  Canada’s  contribution  would  be 
RT  routers  (up  to  20)  and  software,  and  CNCP  would 
provide  the  communications  facilities,  along  with  a  contri¬ 
bution  to  offset  the  cost.  UTCS’  contribution  would  be  the 
non  "out-of-pocket”  expenses  associated  with  the  NOC 
and  the  development.  All  partners'  contributions  are 


planned  to  phase-out  over  a  three  to  five  year  time 
frame,  such  that  the  network  is  fully  self-funding  by  the 
end  of  five  years.  Reaction  to  the  RFI  response  is 
awaited. 


U  of  T  Internet 

The  networking  environment  within  the  University  of 
Toronto  has  also  changed  significantly  in  1988.  Figures 
1  (on  previous  page)  and  2  show  the  configuration  of  the 
U  of  T  Internet  in  December  1987  and  1988  respectively. 

There  has  been  considerable  re-organization  of  existing 
networks  as  well  as  the  addition  of  new  ones.  An  “Exter¬ 
nal  Ethernet"  was  established  to  facilitate  the  connection 


Figure  2 
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Figure  3 


to  the  ONet  universities  via  a  cisco  router.  The  gateway 
to  this  Ethernet  also  connects  to  the  NSFnet  at  Cornell 
and  thence  to  the  ARPAnet.  Several  universities  that  had 
been  previously  connected  to  the  “MCL1”  nodal  proces¬ 
sor  were  moved  to  the  ONet  router.  This  freed  up  capac¬ 
ity  on  MCL1  to  accommodate  the  addition  of  a  connec¬ 
tion  to  the  Faculty  of  Dentistry.  A  local  backbone  was 
installed  in  Sidney  Smith  to  connect  the  existing  Statis¬ 
tics  and  Geography  networks,  as  well  as  new  ones  for 
Math,  Psychology,  Arts,  and  Geography.  Fibre  optic 
cable  was  installed  to  connect  Ethernets  at  Pharmacy 
and  Industrial  Engineering  to  existing  nodal  processors. 

A  Zoology  Ethernet  was  also  connected  to  the  General 
Purpose  Backbone  (GPB)  via  the  nodal  processor  at 
Robarts  Library. 

OCLSC’s  configuration  was  modified  to  establish  a  sepa¬ 
rate  Ethernet  for  the  intimate  connection  of  their  front 


end  and  graphics  systems,  while  retaining  direct  access 
to  the  GPB.  The  Physics/Astronomy  and  CITA  Ethernets 
were  also  reconfigured.  The  IBM  VM  machine 
“UTORONTO",  which  is  being  renamed  to  “VM.UTCS” 
was  more  intimately  connected  to  the  GPB  via  a  7170 
DACU  (Device  Access  Control  Unit),  rather  than  through 
MCL1.  An  UTCS  Ethernet  was  established  to  connect 
UTCS’  PC  and  AppleTalk  networks  to  the  Internet  via  the 
General  Purpose  UNIX  machine  (GPU)  and  to  provide 
an  Ethernet  isolated  from  the  backbone  to  permit  safe 
testing  of  hardware  and  software,  without  impacting  the 
other  users  of  the  Internet.  The  Token  Ring  Backbone 
was  logically  connected  to  the  GPB  via  the  nodal 
processor  at  Sidney  Smith.  This  provided  an  alternate 
path  for  Mechanical  Engineering  and  CCIE  networks  to 
reach  the  GPB,  given  the  unreliability  of  their  path 
through  CSRI’s  Hubnet. 
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A  3174  controller  was  installed  in  the  UTCS  machine 
room  to  provide  both  3270-type  and  Token  Ring  con¬ 
nectivity  to  UTCS’  mainframe  environments. 

Figure  3  depicts  the  various  components  of  the  Univer¬ 
sity's  PACXnet,  which  uses  the  Terminal  Switching  Back¬ 
bone  (TSB)  to  interconnect  local  and  remote  logic 
shelves,  which  in  turn  connect  to  either  clusters  of 
terminals,  or  ports  on  host  machines. 


Micro  Classroom  Upgrade 

The  classroom  in  which  MS-DOS  based  products  are 
taught  was  re-equipped  with  eleven  386-based  machines 
from  AT&T,  and  a  3B2-400  file  server,  at  such  a  sizeable 
discount  from  list  price  that  it  must  be  considered  partly  a 
grant  from  AT&T.  The  previous  machines,  IBM  PC-XTs, 
were  becoming  inadequate  in  terms  of  memory  capacity 
and  power  to  run  the  new,  more  sophiscated  packages. 
Also,  the  AT&T  machines  can  run  both  MS-DOS  and 
UNIX,  which  will  be  an  advantage,  given  the  growing 


popularity  of  UNIX  and  applications  that  run  under  it.  The 
displaced  PC-XTs  were  reallocated  to  UTCS’  Systems 
Group  to  replace  dumb  terminals,  improving  their  support 
of  academic  and  administrative  mainframe  systems. 


4.2  UTCS  Budget  History 

It  may  be  instructive  at  this  point  to  review  the  UTCS 
budget  history  since  monetization  in  1984/85.  Figure  4 
depicts  UTCS’  Gross  Expense  Budget  (GEB),  Net 
Expense  Budget  (NEB)  and  Income  Target  (IT)  since  the 
1983/84  fiscal  year.  The  IT  graph  represents  real  money 
income  since  1984/85.  Prior  to  that  it  was  “funny  money" 
or  entitlements.  The  GEB  and  NEB  were  not  exactly  the 
same  in  1983/84  because  there  was  some  real  money 
income  from  research  grants  and  commercial  users. 
When  monetization  was  implemented  in  1984/85,  the 
most  obvious  effect  was  the  reduction  in  UTCS’  NEB 
from  around  $8  million  to  $4  million.  The  difference 
between  GEB  and  NEB  was  to  come  from  the  Income 
Target,  which  in  that  first  year  was  more  than  $3  million. 


Figure  5 

Figure  4  UTCS  BUDGET  HISTORY 

UTCS  BUDGET  HISTORY  (Adjusted  for  Salary  Increases  and  Add-Backs) 
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In  other  words,  the  amount  of  funding  received  by  UTCS 
from  the  University  was  cut  in  half,  with  the  balance 
required  to  cover  the  GEB  having  to  be  earned  from 
University  or  outside  users,  through  income  from 
machine-based  services,  consulting,  and  facility  man¬ 
agement  arrangements.  On  top  of  the  effects  of  moneti¬ 
zation  was  a  budget  cut  resulting  in  a  very  substantial 
reduction  in  real  expenses,  reflected  by  the  decrease  in 
the  GEB.  The  mechanics  of  monetization  were  such  that 
a  part  of  UTCS’  budget  (about  $1 .4  million  worth)  was 
distributed  to  the  user  community,  based  on  an  algorithm 
that  considered  previous  use  of  entitlement  funds.  (This 
was  done  not  by  UTCS,  but  by  the  Office  of  the  Vice- 
President,  Research.)  Users  could  then  spend  this  real 
money  in  buying  services  from  UTCS  or  anywhere  else, 
so  long  as  it  was  spent  on  computing. 

After  1984/85,  UTCS  was  able  to  reduce  its  expenses, 
with  a  corresponding  reduction  in  Income  Target,  to  the 
tune  of  about  $1 .3  million  over  four  years.  Surprisingly, 
the  NEB  has  consistently  grown  over  the  years,  but  the 
reduction  in  IT  has  kept  the  GEB  almost  constant.  The 
solution  lies  in  Figure  5. 

In  every  fiscal  year,  there  were  several  additions  that 
tended  to  increase  the  annual  budget;  these  were  for 
salary  increases  and  funds  for  specific  projects  or 
initiatives.  Figure  5  shows  the  same  GEB  and  NEB  as  in 
Figure  4,  but  adjusted  to  remove  the  effect  of  the 
cumulative  automatic  salary  increases  (CAI)  each  year. 

In  effect,  the  GEB-CAI  and  NEB-CAI  graphs  show  the 
respective  UTCS  budgets  with  a  constant  salary  level, 
that  of  1984/85. 

Furthermore,  the  Net  Operating  Budget  (NOB)  graph 
shows  UTCS’  budget  without  the  addbacks  that  have 
occurred  over  the  years  for  networking,  administrative 
upgrades  and  software,  etc.  It  shows  a  continuing  de¬ 
cline  in  UTCS'  “operating  budget.” 

Moreover,  if  the  administrative  system  were  treated  as  a 
true  facility  management  operation,  all  the  costs  associ¬ 
ated  with  it  —  the  hardware,  software,  maintenance, 
operations  and  support  (which  add  up  to  over  $1  million) 
—  would  not  appear  in  UTCS’  Net  Operating  Budget  at 
all.  Instead,  they  would  be  a  part  of  the  Gross  Expense 
Budget  and  be  offset  by  income  in  the  Income  Target. 

Thus,  while  gross  budget  figures  appear  to  indicate  a 
rise  in  UTCS’  expense  budgets,  this  is  largely  due  to 
circumstances  beyond  our  control  (short  of  cutting  more 


staff),  and  UTCS  continues  to  become  more  efficient  in 
applying  technological  advances  to  reduce  costs  and 
improve  productivity. 

5.  1989/90  FINANCIAL 
PROJECTIONS 

A  balanced  budget  is  projected  for  next  year.  Any  new 
projects  or  initiatives  would,  of  course,  have  to  be 
explicitly  funded.  The  upgrade  of  the  administrative 
machine  is  an  obvious  example. 

6.  NETWORKING  INITIATIVES 

At  its  January  meeting,  the  UTCS  Board  reviewed  the 
various  networking  initiatives  presented  below  and  as¬ 
signed  two  levels  of  priority.  Items  identified  in  the 
highest  level  of  priority  are  marked  with  two  asterisks 
(**).  Items  in  the  second,  lower,  level  of  priority  are 
marked  with  one  asterisk  (*).  Unmarked  items  were 
deemed  to  be  at  a  third,  even  lower,  level  of  priority  for 
funding. 


6.1  Backbone  Interconnectivity 

Connectivity  among  the  diverse  departments  and 
divisions  at  this  university  is  accomplished  by  the  attach¬ 
ment  of  in-building  Local  Area  Networks  (LANs)  to  the 
inter-building  backbones  installed  and  operated  by 
UTCS.  At  present,  three  distinct  backbones  are  used  to 
satisfy  the  connectivity  needs.  They  are: 

•  General  Purpose  Backbone  (GPB) 

•  Token  Ring  Backbone  (TRB) 

•  Terminal  Switching  Backbone  (TSB) 

As  technology  advances  and  new  facilities  become 
available,  these  distinct  backbones  may  begin  to 
consolidate  in  the  1992  timeframe. 

For  the  present  and  immediate  future,  it  is  desirable  for 
all  three  backbones  to  interconnect,  though  even  with 
interconnection,  it  may  not  always  be  possible  to  have 
identical  functions  on  all  backbones.  Interconnectivity 
between  the  TSB  and  GPB  is  currently  provided  by  a 
device  donated  by  Gandalf.  Unfortunately,  it  only 
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supports  the  DECNET  mode  of  operation  and  not  the 
more  common  TCP/IP  mode.  We  have  received  requests 
from  the  Departments  of  Statistics  and  Physics  to 
provide  for  TCP/IP-based  traffic,  as  well  as  DECNET. 
This  added  connectivity  will  ease  access  to  the  FELIX 
library  system  for  many  researchers  now  using  TCP/IP 
systems.  The  cost  of  this  enhancement  is  $16,000  for  16 
concurrent  terminal  ports**. 


6.2  Terminal  Switching  Backbone 

The  evolution  of  the  GPB  has  identified  an  engineering 
anomaly  with  the  Interlan  terminal  servers  which  were 
bought  in  1984.  These  servers  act  somewhat  as 
surrogate  hosts  to  connect  otherwise  stand-alone 
terminals  to  remote  hosts  on  the  GPB.  They  now  fail  to 
handle  broadcast  packets  correctly  and,  as  a  result,  fairly 
regularly  become  inoperative.  These  units  are  no  longer 
being  manufactured  and  the  company  that  produced 
them  has  been  sold  at  least  once.  Repeated  efforts  to 
obtain  a  resolution  to  the  problem  from  the  supplier  have 
been  unsuccessful.  In  order  that  we  may  provide  for  full 
dynamic  routing  on  the  GPB,  these  servers  must  be 
replaced.  It  is  proposed  that  they  be  replaced  by  devices 
called  remote  shelves,  which  are  remote  extensions  of 
our  Gandalf  terminal  switch  on  the  TSB.  Some  of  the 
necessary  equipment  has  been  donated  by  Gandalf  for 
field  trials  that  UTCS  performed  in  previous  fiscal  years. 
Hence,  it  is  not  necessary  to  obtain  new  shelves.  The 
anticipated  cost  for  this  replacement  is  $8,500**. 

It  appears  that,  at  least  initially,  the  Earth  Sciences 
Building  will  have  a  number  of  terminals  which  are  not 
connected  to  local  computers,  but  rather  to  the  TSB  via 
the  PACX.  A  remote  PACX  shelf  located  in  the  building 
should  handle  the  expected  needs  over  the  next  fiscal 
year.  This  request  is  in  addition  to  the  requirement  for  a 
GPB  nodal  processor.  The  two  devices  satisfy  different 
needs.  The  TSB  shelf  will  be  configured  to  handle  the 
first  year’s  needs  only.  A  remote  shelf  can  connect  up  to 
128  physical  terminals.  The  costs  for  this  additional  shelf 
will  be  $18,500*. 


6.3  Physical  Infrastructure 

The  term  “physical  infrastructure”  means  the  actual  com¬ 
munications  cabling  and  cable  tray.  The  UTCS  design 
philosophy  is  to  incrementally  connect  increasing  areas 


of  the  campus  with  both  optical  fibre  and  some  copper 
cable.  These  increases  in  coverage  and  connection 
have  been  occurring  for  a  number  of  years  as  funds 
have  permitted.  The  standards  we  established  for  the 
two  types  of  cable  are: 

•  12  strand  fibre  cable 

•  1 00  pair  copper  twisted  pair 

It  is  recognized  that  neither  of  these  cable  sizes  are  par¬ 
ticularly  large.  They  have,  however,  permitted  the 
growth  of  a  very  effective  campus  networking  environ¬ 
ment.  The  actual  costs  for  the  installation  of  this  infra¬ 
structure  are  dominated  by  labour  charges  and  the  cost 
of  cable  tray  where  that  is  needed,  not  by  the  cost  of  the 
cable  itself.  Cable  tray  is  deemed  necessary  by  Physical 
Plant. 

During  fiscal  1989/90,  it  is  suggested  that  the  following 
enhancements  be  made  to  the  infrastructure.  Both  types 
of  cable  will  be  installed,  as  necessary: 

•  Add  to  the  existing  cable  between  McLennan 
Labs  and  Sidney  Smith  ($25,000)  ** 

•  Cable  from  Sandford  Fleming  to  Simcoe  Hall 
($15,500) 

•  Cable  from  Simcoe  Hall  to  the  School  of 
Graduate  Studies  ($30,000) 

•  Re-organize  the  Sandford  Fleming  Hub 
($4,000) 

The  amount  of  cable  needed  to  execute  all  the  above 
plans  is: 

•  1.5  km  of  fibre  ($15,000) 

•  500  m  of  copper  twisted  pair  ($3,000) 

These  estimates  have  been  generated  by  UTCS  and 
Physical  Plant.  The  cost  of  cable  tray  is  included,  as 
necessary.  The  rationale  for  these  infrastructure 
investments  is  further  elaborated  in  the  backbone 
expansion  plans. 


6.4  Token  Ring  Expansion 

Both  the  Library  Administration  and  the  School  of 
Graduate  Studies  have  made  a  significant  investment  in 
token  ring  Local  Area  Networks  within  their  buildings 
during  fiscal  year  1988/89.  Connecting  these  local 
systems  to  the  backbone  environments  would  signifi- 
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cantly  increase  their  utility.  Fibre  currently  goes  to  the 
Medical  Sciences,  Robarts  and  Sigmund  Samuel  librar¬ 
ies.  Hence,  the  requirement  to  achieve  connectivity  is 
only  the  provisioning  of  TRB  nodal  processors  (IBM  PC 
bridges)  and  repeaters.  If  the  request  for  fibre  to  the  SGS 
buildings  is  approved,  they  will  require  connection  to  the 
TRB.  Repeaters  and  bridges  will  cost  approximately 
$25,000  for  each  site  for  a  total  of  $1 00,000.  (The  Ro¬ 
barts  Library  connection  received  second  level  priority*.) 


6.5  General  Backbone  Expansion 

The  Departments  of  Chemical  Engineering  and  Metal¬ 
lurgy  have  expressed  the  need  for  connection  to  the 
GPB.  Since  fibre  already  reaches  their  building,  they 
only  need  to  install  a  nodal  processor,  which  both  depart¬ 
ments  could  share.  A  nodal  processor  and  associated 
equipment  for  this  requirement  would  cost  $25,000. 

Last  year’s  Annual  Plan  suggested  that  the  Earth 
Sciences  Complex  would  eventually  require  attachment 
to  the  GPB.  Internal  building  wiring  for  data  communica¬ 
tions  and  the  extension  of  fibre  cable  to  wiring  closets  in 
the  building  should  be  completed  this  fiscal  year.  If  intra¬ 
building  networks  are  installed  by  the  building  occupants 
next  year,  then  it  may  be  appropriate  to  connect  these 
internal  networks  to  the  GPB.  If  this  requirement  occurs 
during  1989/90,  then  a  nodal  processor  will  be  required. 
The  cost  of  this  connection,  as  above,  would  be  $25,000. 

7.  INFORMATION  CENTRE 
INITIATIVES 

7.1  Hardware/Software  Upgrade  Fund 

UTCS  Board  members  noted  that  every  year  UTCS  puts 
forward  requests  for  funding  of  initiatives  of  one  sort  or 
another  for  the  Information  Centre.  Because  of  the  recur¬ 
ring  nature,  they  felt  that  these  items  should  not  be  con¬ 
sidered  as  requests  for  one-time-only  funding.  UTCS 
should  instead  establish  an  internal  fund  to  cover  these 
annual  expenses.  Examples  of  such  expenses  are  up¬ 
grades  to  existing  hardware,  seed  money  for  software 
site  licenses,  new  hardware  that  is  gaining  popularity  in 
the  university,  and  microcomputers  specifically  assigned 
to  individual  consultants  for  their  day-to-day  use. 


7.2  Future  Direction 

Increasingly,  information  is  being  created,  manipulated 
and  presented  with  the  aid  of  computers.  As  a  result  of 
this  phenomenon,  people  have  become  increasingly 
aware  of  the  need  to  have  effective  presentation  of 
information.  The  most  popular  example  of  this  is  the 
layout  and  graphical  design  required  for  effective 
desktop  publishing.  Specifically,  not  only  must  the 
contentual  information  be  provided,  but  it  must  be 
presented  within  the  context  of  the  medium.  Another  ex¬ 
ample  may  be  found  where  a  computer  itself  is  used  to 
present  the  information  in  a  very  effective  manner,  such 
as  the  Kanji  HyperCard  development  at  U  of  T. 

In  the  past,  UTCS  has  hired  staff  from  non-computing 
disciplines,  to  bridge  the  chasm  between  area  of  applica¬ 
tion  and  computer  technology.  For  example,  we  have 
regularly  hired  statisticians  to  assist  in  the  support  of 
computer-based  statistical  packages,  and  humanists  to 
provide  support  in  text-related  areas. 

To  foster  an  awareness  of  this  design  issue,  and  to 
promote  effective  development  of  this  style  of  applica¬ 
tion,  we  propose  to  hire  a  person  skilled  in  the  applica¬ 
tion  of  graphic  design  in  computer  programming.  This 
person  would  assist  users  creating  documents,  forms, 
transparencies,  and  electronic  publications.  A  full-time 
salary  for  a  position  of  this  calibre  would  be  about 
$40,000  annually.  Members  of  the  UTCS  Board 
supported  this  request. 

8.  CENTRAL  ADMINISTRATIVE 
SYSTEMS 

8.1  Machine  Replacement 

When  the  existing  administrative  machine,  an  IBM  4381 
R14,  was  last  upgraded  in  November  1987,  it  was  with 
the  understanding  that  no  further  increase  in  capacity 
would  be  needed  or  requested  until  1989/90.  Monitoring 
of  system  usage  has  indeed  indicated  that  the  cpu  will  be 
out  of  capacity  before  May  1989,  and  projections  of  the 
capacity  requirements  of  growth  in  existing  applications 
and  planned  ones  indicate  that  a  machine  of  approxi¬ 
mately  two  and  a  half  times  the  power  of  the  existing  one 
would  be  needed  to  satisfy  the  administrative  processing 
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requirements  for  three  years,  after  which,  this  new 
machine  would  also  be  out  of  capacity.  The  existing  cpu 
is  popularly  rated  as  having  6.0  Mips  (Million  instructions 
per  second)  of  power.  A  replacement  cpu  would  have  to 
have  about  15  Mips  of  capacity.  This  can  be  provided  in 
various  ways  by  several  vendors,  all  of  whose  products 
are  IBM-compatible.  Compatibility  with  IBM  is  necessary 
to  protect  the  University’s  investment  in  data  base  and 
application  software  development.  To  convert  to  a  non- 
IBM  software  environment  would  entail  an  expenditure  of 
millions  of  dollars  and  several  years  of  effort. 

The  Technical  Subcommittee  of  the  Administrative  Com¬ 
puting  Committee  reviewed  various  scenarios,  presented 
by  UTCS,  for  replacing  the  machine  by  a  current  or  older 
generation  machine  from  IBM,  Amdahl,  or  NAS.  After 
weighing  the  financial,  technical,  and  practical  ramifica¬ 
tions  of  each  alternative,  a  second-generation  IBM  ma¬ 
chine  was  selected.  This  was  based  on  the  fact  that  the 
features  offered  by  the  current  generation  technology 
(ESA)  were  not  deemed  to  be  necessary  within  the  three 
year  timeframe,  and  could  not  justify  the  more  than  ten¬ 
fold  increase  in  capital  cost.  Assuming  the  funding  for  the 
replacement  is  approved,  an  IBM  3081 -K  will  be  installed 
in  May  1989.  As  part  of  the  machine  replacement, 
additional  disk  storage  (5  Gigabytes)  is  necessary  and 
included  in  the  plan,  as  is  the  upgrading  of  the  tape  sub¬ 
system,  described  below. 

8.2  Upgrading  the  Administrative  Tape 
Subsystem 

In  the  past  two  Annual  Plans,  UTCS  has  recommended 
the  upgrading  of  the  obsolete  tape  subsystem  on  the  ad¬ 
ministrative  machine,  from  3420  tape  reel  technology, 
which  is  now  12  years  old  and  even  more  obsolete,  to 
the  current  3480  tape  cartridge  system.  Deteriorating 
reliability  of  the  old  tape  drives,  coupled  with  continuing 
growth  in  the  size  of  the  tape  library  and  in  disk  storage 
requiring  backup,  force  action.  The  old  tape  drives,  with 
a  data  transfer  rate  of  0.47  megabytes  (MB)  per  second, 
would  create  an  intolerable  bottleneck  in  an  upgraded 
cpu  when  the  newer  3480s  transfer  data  at  3.0MB  per 
second  —  a  greater  than  six-fold  increase.  For  these  and 
other  reasons  (to  do  with  floor  space,  media  cost, 
storage  space  etc.),  UTCS  has  included  a  tape  subsys¬ 
tem  upgrade  as  an  integral  part  of  the  machine  replace¬ 
ment  plan.  It  is  planned  to  be  funded  from  the  proceeds 
of  the  disposition  of  the  existing  cpu. 


8.3  Increased  Network  Access  to  the 
Administrative  System 

Greatly  increased  access  to  the  administrative  system 
can  be  provided  once  the  TSB  and  GPB  are  intercon¬ 
nected,  as  described  in  Section  6.1 .  This  would  allow 
users  on  departmental  machines  to  be  able  to  connect  to 
our  PACX,  then  to  the  7171  protocol  converter  on  the  ad¬ 
ministrative  machine.  This  mode  of  connection  is  subject, 
however,  to  concerns  about  both  security  and  integrity  of 
data.  These  concerns  will  need  to  be  resolved  before 
widespread  access  through  this  means  can  be  permitted. 

Plans  are  also  underway  to  provide  token  ring  access  to 
the  administrative  system.  Users  who  now  have  local 
token  rings,  such  as  the  Robarts  Library,  Office  of 
Academic  Statistics  and  Records,  and  the  School  of 
Graduate  Studies,  and  those  who  are  considering  them, 
as  at  215  Huron,  will  be  able  to  connect  to  the  mainframe 
via  the  TRB  and  UTCS’  3174.  As  described  in  Sections 

6.3  and  6.4,  additional  cabling,  nodal  processors,  and 
repeaters  are  needed  to  connect  some  sites. 

9.  EMERGING  SUPPORT  AREAS 

9.1  Data  Library  Service 

A  proposed  “Data  Library  Service”  (DLS)  was  described 
in  last  year’s  Plan.  It  was  identified  as  an  “emerging 
support  area”  then,  and  appears  to  be  still  emerging. 

This  service  was  to  be  a  co-operative  project  between 
the  University  of  Toronto  Library  (UTL)  and  UTCS.  Its 
intent  was  to  provide  ready  access  to  machine-readable 
data,  the  initial  collection  of  which  was  to  be  the  approxi¬ 
mately  260  tapes  of  census  information,  presently  stored 
at  UTCS.  Additional  acquisitions  would  depend  on  UTL’s 
acquisition  budget. 

Since  the  access  to  data  in  the  DLS  was  expected  to  be 
of  a  sporadic  nature,  in  that  a  researcher  would  require 
infrequent  extractions  of  a  particular  subset  of  available 
data,  which  would  then  be  transferred  to  the  user’s  own 
PC  or  departmental  machine  for  further  analysi  s,  UTCS 
was  prepared  to  assist  users  in  formulating  and  effecting 
the  initial  extraction  and  transfer  to  the  user’s  “home" 
system,  rather  than  attempt  to  produce  generalized, 
meaningful  procedures  and  documentation  on  how  users 
could  do  the  extraction  themselves. 


ComputerNews  /  APRIL  1989  13 


UTCS  was  prepared  to  contribute  the  opportunity  costs 
of  the  UTCS  staff  associated  with  this  project  ($52,500), 
but  funding  was  requested  for  out-of-pocket  and  facility 
management  expenses  ($62,200).  UTL  was  able  to 
cover  $20,000  of  the  out-of-pocket  expenses  for  data 
base  software,  and  hired  a  support  person,  but  the  bal¬ 
ance  of  $42,200  for  UTCS  expenses  remained  un¬ 
funded.  This  year,  the  Board  felt  it  was  more  appropriate 
for  the  UTL  to  request  the  funds  on  behalf  of  UTCS. 

9.2  Academic  Information  Data  Base 
System 

UTL  has  submitted  a  proposal  for  the  establishment  of 
an  Academic  Information  Data  Base  System  (AIDBS), 
which  would  develop  an  electronic  delivery  system  for 
the  Toronto  Health  Sciences  information  network,  pro¬ 
vide  electronic  database  searching  of  abstracts,  indexes 
and  reference  tools  via  the  campus  network,  and  test  a 
prototype  electronic  Canadian  library  of  1 ,000  texts.  This 
system  would  require  considerable  data  storage  and 
computing  resources,  as  well  as  intimate  connection  to 
the  University’s  existing  and  developing  communications 
networks.  Should  UTL  be  successful  in  establishing 
AIDBS,  UTCS  would  be  prepared  to  interface  it  to  the 
various  network  environments,  much  as  we  have  for 
FELIX,  the  catalogue  system,  as  well  as  operate  and 
support  the  system  under  a  facility  management  agree¬ 
ment.  If  UTL  is  not  successful,  UTCS  would  be  inter¬ 
ested  in  exploring  the  gradual  phasing-in  of  parts  of 
AIDBS  on  existing  facilities,  to  whatever  level  capacity 
and  funding  may  permit. 


9.3  Workplace  Hazardous  Material 
Information  System 

UTCS  has  been  co-operating  with  the  Office  of  Environ¬ 
mental  Health  and  Safety  (EHS)  in  exploring  ways  to 
provide  access  to  Workplace  Hazardous  Material  Infor¬ 
mation  System  (WHMIS)  data  to  comply  with  the  legisla¬ 
tion  regarding  hazardous  chemicals  in  the  workplace  that 
took  effect  last  November.  For  initial  compliance  with  the 
legislation,  much  of  the  WHMIS  data  is  available  on  CD- 
ROM  disks  produced  by  the  Canadian  Centre  for  Occu¬ 
pational  Health  and  Safety  (CCOHS).  EHS  has  distrib¬ 
uted  many  CD-ROM  readers  to  departments  with  large 
concentrations  of  potentially  hazardous  chemicals,  such 
as  Medicine,  Chemical  Engineering,  Chemistry,  and  so 
on.  This  may  not  be  a  satisfactory  long-term  solution 
however,  because  the  CD-ROMs  distributed  by  CCOHS 
are  not  necessarily  complete,  in  that  some  manufactur¬ 
ers  refuse  to  provide  machine  readable  data  to  CCOHS, 
preferring  to  sell  their  own  CD-ROMs,  and  it  may  be  im¬ 
practical  to  provide  the  potentially  large  numbers  of  CD- 
ROM  readers,  and  controlling  PCs,  to  allow  the  neces¬ 
sary  access  points  to  satisfy  the  legislation.  UTCS  is 
exploring  longer-term  solutions,  which  may  include  a 
WHMIS  server  on  the  campus  network,  multiple  network- 
accessible  CD-ROM  readers  acting  as  servers,  a 
centralized  WHMIS  data  base  on  the  administrative 
machine,  or  even  direct  access  to  a  central  WHMIS  data 
base  on  a  distant  machine,  such  as  at  McMaster,  via 
ONet.  The  functionality  versus  the  cost-effectiveness  of 
the  various  alternatives  will  be  examined,  in  concert  with 
EHS. 
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The  State  of  386s 
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I  n  July  1986,  a  small  company 
I  called  Advanced  Logic  Research 
released  the  first  IBM  PC-compatible 
based  on  the  Intel  80386  microproc¬ 
essor.  Even  though  ALR  did  not 
ship  any  80386s  until  late  1986, 
other  manufacturers  quickly  followed 
ALR’s  lead  with  announcements  of 
their  own.  That  September,  Compaq 
introduced  the  Deskpro  386,  a  16 
Megahertz  (MHz)  80386  with  one 
megabyte  (MB)  RAM  and  a  40MB 
hard  disk.  IBM  followed  suit  in  April 
of  1987,  announcing  their  PS/2  line 
of  machines,  including  the  80386- 
based  Model  80.  Since  then,  numer¬ 
ous  manufacturers  have  announced 
and  released  80386-based  ma¬ 
chines. 

Who  needs  a  386?  If  you  determine 
that  you  need  one,  which  manufac¬ 
turer  do  you  go  with?  Which  model 
do  you  buy?  What  are  the  differ¬ 
ences  between  models?  These  and 
many  other  questions  about  80386- 
based  machines  are  being  asked 
more  often  at  the  University  of 
Toronto.  We  hope  this  article  will 
help  you  determine  if  you  really  need 
a  386  and  give  you  some  idea  about 
which  model  to  buy. 


How  Fast  Can  it 
Go? 

With  the  current  state  of  software, 
very  few  people  must  buy  a  386  in 
order  to  do  their  computing.  How¬ 
ever,  this  does  not  mean  that  you 


don’t  need  a  386,  or  that  one 
wouldn’t  make  your  computing  life 
easier. 

In  the  DOS  world,  an  80286  or 
80386  chip  is  treated  by  the  operat¬ 
ing  system  as  an  8088  because 
these  more  advanced  microproces¬ 
sors  are  downwardly  compatible  with 
the  original  8088.  DOS  itself,  and 
about  95%  of  DOS  software,  does 
not  take  advantage  of  any  of  the 
additional  features  provided  by  the 
80286  and  80386  microprocessors. 
However,  these  chips  are  driven  by 
faster  clocks  and  thus  perform 
individual  instructions  in  less  time 
than  the  8088.  So,  the  first  reason 
that  you  may  have  for  buying  an 
80386-based  machine  is  its  speed. 

How  much  faster  is  an  80386-based 
machine  than  the  original  IBM  PC? 
Benchmark  tests  show  that  an  8MHz 
80286  is  approximately  4  times 
faster  than  a  4.77MHz  8088,  and 
that  a  16MHz  80386-based  machine 
is  almost  twice  as  fast  as  the  80286. 
Of  course,  these  figures  only 
indicate  the  minimum  speed 
increases  obtained  on  the  faster 
machines  —  the  actual  speed 
increase  is  greater  because  of  the 
enhanced  features  of  the  chips. 

Which  types  of  programs  require 
blazing  speed?  Some  examples 
include  numerical  analysis  programs, 
large  database  programs,  complex 
graphics  programs,  and  any  other 
programs  that  process  large 
amounts  of  data.  File  servers  for 


busy 

local  area 
networks 
also  call  for 
the  enhanced  processing  power  of 
machines  based  on  these  chips. 


Crystal  Balls,  Any¬ 
one? 

Another  reason  to  buy  a  386  is  to 
provide  for  the  future.  Some 
programs  available  today  require  an 
80386-based  machine  (Microsoft 
Windows/386,  Paradox  386,  and 
DESQview  386,  to  name  a  few),  and 
more  will  be  released,  to  be  sure. 
Most  of  these  programs  take 
advantage  of  the  additional  features 
of  the  80386  in  order  to  provide  a 
multi-tasking  environment  or  to 
extend  the  amount  of  memory  that  a 
program  may  address.  For  example, 
the  recently  announced  Release  3  of 
Lotus  1-2-3  will  require  an  80286-  or 
80386-based  machine.  As  more  of 
these  types  of  programs  appear  on 
the  market,  8088-based  machines 
(and  even  80286-based  machines) 
may  not  have  the  computing  power 
or  the  capability  to  run  these  pro¬ 
grams.  Many  software  vendors  now 
recommend  that  their  high-end 
software  be  run  on  80286-  or  80386- 
based  machines,  claiming  that  you 
would  be  disappointed  with  the 
performance  on  an  8088  and 
implying  that  new  versions  of  the 
software  may  require  them. 
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Furthermore,  OS/2,  the  multi-tasking 
operating  system  for  IBM  PCs  and 
compatibles,  will  not  run  on  8088- 
based  micros.  The  program  requires 
at  least  an  80286  microprocessor 
because  it  takes  advantage  of  the 
extended  features  of  this  chip.  As 
OS/2  grows  and  more  applications 
are  written  to  take  full  advantage  of 
it,  even  80286-based  micros  will  start 
to  run  out  of  computing  power.  This 
may  be  another  reason  you  might 
have  for  choosing  an  80386-based 
machine. 


Which  386  is 
Which? 

So  now  you've  decided  to  buy  a  386, 
but  as  you  browse  the  stores  and  the 
available  literature,  you  realize  that 
there  are  numerous  models  and 
options,  even  from  individual 
manufacturers  (a  quick  count  of 
offerings  in  the  latest  PC  Magazine 
found  no  less  than  37  systems  from 
21  manufacturers).  What  do  you 
do? 

Generally,  there  are  three  types  of 
80386-based  micros  available  today, 
with  more  coming  soon.  At  the  low 
end  are  machines  powered  by  the 
slowest  of  the  80386  chips,  running 
at  a  mere  16MFIz.  In  the  middle  of 
the  range  are  the  machines  powered 
by  20MHz  chips.  The  high  end  of 
the  80386  market  features  the 
25MFIz  machines,  complete  with 
hardware  RAM  caches,  huge- 
capacity  hard  disks,  lots  of  memory, 
and  high  price  tags. 

The  16MHz  machines,  typically 
referred  to  as  the  workhorse  386s, 
are  the  slowest  and  least  expensive 
of  the  group.  Almost  every  manufac¬ 
turer  of  PC  compatibles  has  a 


16MFfz  386  in  their  product  line, 
available  in  a  variety  of  RAM  and 
hard  disk  configurations.  If  you  are 
satisfied  with  the  performance  of  the 
software  on  your  AT  now,  but  are 
thinking  of  using  more  of  the  leading- 
edge  programs  in  the  future,  these 
entry-level  386s  may  be  for  you. 

The  20MHz  386s  perform  at  least 
25%  faster  than  the  16MPIz  variety 
simply  because  of  their  faster  clock 
speed.  However,  some  manufactur¬ 
ers  add  a  hardware  RAM  cache, 
further  increasing  the  performance  of 
the  machines. 


Cash  or  Cache! 

A  cache  is  a  small  amount  (usually 
32KB  or  64KB)  of  very  fast  RAM 
controlled  by  a  cache  controller. 
When  the  microprocessor  requests 
data  from  main  memory,  the 
contents  of  the  RAM  cache  are 
checked  first.  If  the  requested  infor¬ 
mation  is  found  in  the  cache,  it  can 
be  accessed  by  the  microprocessor 
quickly.  If  it  is  not  found,  the  slower 
main  memory  must  be  accessed. 
Thus,  the  RAM  cache  allows  the 
manufacturer  to  increase  the 
performance  of  the  machines  without 
a  major  cost  increase. 

Who  are  the  20MHz  machines 
designed  for?  Eight  months  ago, 
these  machines  were  the  ultimate  in 
performance,  but  now  they  exist  in  a 
grey  area  of  the  market,  thanks  to 
the  availability  of  25MHz  machines. 
Professional  desktop  publishers  will 
find  the  price/performance  ratio  of 
these  machines  to  be  satisfactory, 
as  will  users  of  CAD  packages, 
statistical  and  numerical  analysis 
packages,  programs  with  large 
databases,  and  other  power-hungry 
programs. 


Speed  Limits:  Slow 
Down,  Please! 

Now,  most  larger  manufacturers 
produce  25MHz  machines.  The 
ultimate  in  technology,  standard 
features  on  these  machines  usually 
include  hardware  static  RAM  caches, 
large  fast  hard  disks,  2MB  or  more  of 
RAM,  VGA  video,  and  other  leading- 
edge  features.  But  these  machines 
do  not  come  cheap.  After  adding  a 
tape  backup  system,  extra  RAM,  a 
math  coprocessor,  a  VGA  color 
monitor,  and  the  software  to  take 
advantage  of  all  this  power,  these 
systems  cost  $15,000  or  more,  not 
including  printers,  plotters,  graphics 
tablets,  and  other  I/O  devices. 

The  market  for  these  machines  is  not 
large,  and  that  is  one  reason  why  the 
machines  are  so  expensive.  Users 
of  large  CAD  packages,  mainframe- 
type  database  programs,  calculation¬ 
intensive  programs,  and  multi¬ 
tasking  operating  systems  are  about 
the  only  people  who  can  push  these 
machines  to  their  full  potential. 

Just  as  20MHz  machines  were 
surpassed  by  25MHz  machines, 
these  may  soon  become  the  entry- 
level  386s.  Intel  (the  manufacturer 
of  the  80386  microprocessor)  has 
already  announced  a  33MHz  chip, 
with  quantity  delivery  expected  this 
spring.  And  the  80486,  an  upgrade 
to  the  80386,  will  start  shipping  in 
the  fourth  quarter  of  this  year. 
Machines  built  around  this  chip  are 
expected  to  be  announced  early  next 
year.  So,  hold  on  to  your  hats.  We 
may  be  doing  things  with  micros  in 
1990  that  we  can’t  even  begin  to 
imagine  today! 
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A  department  on  campus  recently 
purchased  Macintosh  computers 
for  its  administrators.  The  depart¬ 
ment  required  relatively  high-quality 
laser  printers,  but  at  a  cost  of  $5000 
per  printer,  each  person  could  not 
get  one.  The  department  opted  to 
install  only  two  laser  printers  and 
connect  them  to  each  computer  via  a 
network.  This  is  easy  to  do  because 
every  Mac  comes  with  the  hardware 
and  software  needed  to  participate 
on  an  AppleTalk  network.  By  buying 
laser  printers  that  are  equipped  for 
AppleTalk,  and  by  connecting  the 
appropriate  wiring  between  them 
and  the  Macs,  it  became  possible  to 
share  the  printers. 

Back  in  1969,  the  American  Defense 
Advanced  Research  Projects 
Agency  (DARPA)  found  that  it  was 
funding  expensive  computers  that 
were  being  underutilized.  To 
encourage  sharing  of  time  on  these 
computers,  it  established  the 
ARPAnet  network,  by  which  large 
computers  were  connected  to  each 
other.  Researchers  with  appropriate 
hardware,  software,  and  physical 
wiring  to  the  network  could  then  get 
access  to  these  otherwise  idle 
computers,  even  if  the  computers 
were  at  distant  locations. 

Computer  networks  come  in  all 
sizes,  from  departmental  networks 
that  connect  a  few  Macs  in  an  office, 
to  campus-wide  networks  that 
connect  hundreds  of  machines,  to 
networks  that  connect  the  universi¬ 


ties  of  Western 
nations.  Networks 
are  frequently 
created  to  permit 
sharing  of  informa¬ 
tion  or  equipment 
in  a  more  efficient 
or  economical 
manner.  The 
result,  however, 
frequently  goes 
beyond  these 
goals,  altering  the 
very  method  of 
interaction  with 
the  computer  and 
even  between 
people. 

In  the  case  of  the  department  with 
the  AppleTalk  network,  the  adminis¬ 
trators  began  to  use  their  network  for 
more  than  printer  sharing.  To  begin 
with,  they  found  that  documents  and 
inter-office  memos  can  be  sent 
electronically  between  Macs  on  the 
network.  In  the  case  of  ARPAnet, 
researchers  used  the  ability  to  send 
mail  and  documents  electronically  to 
exchange  ideas  with  their  colleagues 
across  the  continent  and,  eventually, 
around  the  globe.  Researchers 
found  that  they  could  work  on  papers 
jointly  by  sharing  their  contributions 
on  a  daily  basis.  Using  electronic 
mail,  they  were  able  to  build  elec¬ 
tronic  bulletin  boards  and,  through 
these,  hold  the  equivalent  of  forums 
and  conferences.  As  these  cases 
demonstrate,  the  work  being  done 
on  the  computer  slowly  began  to 
change  because  of  the  networks. 


Networks  vary  in  the  kind  of  func¬ 
tions  they  provide.  The  NetNorth 
network  (created  and  used  by 
Canadian  universities)  does  not 
provide  as  many  services  as  does 
the  ARPAnet,  mentioned  above. 
Nevertheless,  in  order  to  understand 
computer  networks  and  their  impact 
on  modern  university  computing,  it  is 
useful  to  talk  about  some  of  the 
possible  services  a  network  can 
provide: 


Electronic  Mail 

Electronic  mail,  or  e-mail  for  short, 
allows  you  to  send  messages  to 
users  on  other  computers.  Fre¬ 
quently,  the  message  looks  similar  to 
an  office  memo,  with  a  “To”  line, 
“Subject”  line,  and  “CC”  lines  at  the 
top,  and  a  text  area  below.  Some  e- 
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mail  systems  go  a  step  further  and 
permit  sending  diagrams  or  other 
graphics.  Some  record  and  transmit 
words  spoken  into  a  microphone, 
allowing  users  to  send  and  receive 
voice-messages.  E-mail  was  once 
available  only  to  users  of  mainframe 
or  mini  computers.  However,  it  is 
now  possible  for  users  of  desktop 
workstations  and  personal  comput¬ 
ers  to  send  and  receive  e-mail 
without  using  a  larger  computer. 


File  Transfer 

File  transfer  permits  you  to  get  files 
from  and/or  send  files  to  another 
computer.  If  you  have  used  Kermit 
to  copy  a  file  from  a  computer  to 
your  personal  computer,  then  you 
have  used  a  simple  two-computer 
“network."  The  Internet  networks, 
which  include  ARPAnet  and  connect 
thousands  of  computers  in  hundreds 
of  institutions,  use  FTP  (file  transfer 
protocol)  to  list,  send,  and  receive 
files.  Using  FTP,  a  researcher  at  this 
university  can  copy  files  at  very  high 
speed  to  or  from  a  colleague’s 
computer  at  almost  any  other 
university  in  North  America.  On  the 
NetNorth/BITNET/EARN  networks, 
SENDFILE  serves  a  similar  purpose, 
though  it  only  permits  files  to  be 
sent. 

How  does  e-mail  differ  from  file 
transfer?  E-mail  is  actually  a  special 
case  of  file  transfer  where  the 
format,  that  is,  the  office  memo 
appearance,  has  been  formally 
agreed  on  by  system  administrators. 
Most  computer  systems  provide 
tools  to  compose  and  send  e-mail, 
and  your  recipient’s  computer  will 
probably  recognize  it  as  e-mail  and 
permit  it  to  be  read  by  your  recipient. 
On  the  other  hand,  when  you  send  a 
file,  it  could  be  data,  a  program,  a 
spreadsheet,  or  any  other  type  of 
file. 


Network  File  Sys¬ 
tems 

Using  a  network  file  system,  a  disk, 
or  part  of  a  disk,  located  on  one 
computer  can  be  made  to  look  as  if  it 
is  located  on  one  or  several  other 
computers.  This  is  also  known  as  a 
remote  file  system,  a  remote  virtual 
disk  system,  or  a  distributed  file 
system.  Using  a  network  file  system 
such  as  that  provided  by  Novell  or 
VINES,  many  departments  at  this 
university  buy  one  or  two  personal 
computers  with  large  hard  disks  to 
act  as  “file  servers.”  Connected  to 
these  are  groups  of  personal 
computers  that  have  no  hard  disks, 
but  are  set  up  to  act  as  if  they  have 
one  or  more  hard  disks.  Some  of 
these  “imaginary”  or  virtual  hard 
disks  can  be  shared  among  all  the 
personal  computers.  This  might  be 
used,  for  example,  to  have  everyone 
run  the  same  copy  of  dBASE  or 
WordPerfect.  This  type  of  sharing 
can  save  disk  space  and  mainte¬ 
nance  time  because  only  one  central 
copy  of  a  program  need  be  installed. 
(Of  course,  you  must  still  pay  for 
multiple  copies  of  the  application, 
although  many  vendors  now  offer 
special  discounts  for  network 
versions  of  shared  applications.) 
Virtual  disks  can  also  be  set  up  so 
that  each  user  can  have  a  personal 
disk. 

In  the  UTCS  Information  Centre,  a 
network  file  system  provided  by  a 
Sun  TOPS  network  is  used  to 
connect  an  Apple  Macintosh  to  an 
IBM  PC.  From  the  Mac,  the  hard 
disk  on  the  PC  looks  like  a  Mac  disk, 
and  vice-versa.  This  network  is  used 
to  move  files  back  and  forth  between 
the  Mac  and  PC  environments. 

Using  similar  software,  we  have  also 
connected  our  Macs  to  our  UNIX 
minicomputers.  With  this  setup,  a 
Mac  user  can  access  all  UNIX  files 
as  if  they  were  on  a  Mac  hard  disk. 


Across  campus,  many  departments 
are  saving  money  by  buying  diskless 
UNIX  workstations  and  then  using 
Sun’s  NFS  (Network  File  System) 
and  file  servers.  The  file  servers  are 
usually  larger  UNIX  machines  with 
large  hard  disks. 

How  does  file  transfer  compare  with 
network  file  systems?  With  file 
transfer,  if  a  copy  of  a  file  is  required 
at  two  locations,  it  must  use  up  disk 
space  on  both  computers;  with  a 
network  file  system,  disk  space  is 
only  used  for  one  copy.  With  file 
transfer,  however,  a  file  moves 
across  the  network  only  once;  with  a 
network  file  system,  if  a  file  is 
repeatedly  used  across  a  network,  it 
must  be  transmitted  each  time. 

Using  a  network  can  thus  affect 
performance  because  it  is  often 
slower  to  move  files  over  the  network 
than  it  is  to  get  the  files  directly  from 
a  hard  disk.  If  may  also  be  more 
expensive  to  use  a  network,  if 
network  usage  must  be  paid  for. 

For  the  computer  user,  network  file 
systems  tend  to  be  easier  to  use 
than  file  transfer.  With  file  transfer, 
commands  must  be  learned  in  order 
to  send  files  through  the  network. 
With  network  file  systems,  however, 
the  illusion  of  a  local  disk  is  often  so 
complete  that  no  new  commands 
need  be  learned  —  the  computer 
user  only  needs  to  know  how  to 
handle  the  application  files.  Of 
course,  because  additional  informa¬ 
tion  must  be  sent  through  the 
network  in  order  to  create  the  illusion 
of  local  disks,  the  network  overhead 
is  generally  higher. 

Deciding  if  a  network  file  system  or 
file  transfer  is  most  appropriate  in  a 
given  situation  depends  on  the  type 
of  computer  user,  the  size  of  the  files 
involved,  the  frequency  of  access, 
the  speed  of  the  network,  as  well  as 
a  number  of  other  factors. 


18  ComputerNews  /  APRIL  1989 


Network  Database 
Systems 

In  a  basic  network  database,  a 
single  database  can  be  shared 
across  a  network  by  multiple  users. 
One  way  to  implement  this  type  of 
shared  database  is  to  use  a  network 
filesystem.  For  example,  a  dBASE 
database  of  chemical  formulae  on 
your  personal  computer  could  be  set 
up  to  be  read,  by  your  colleagues, 
across  a  network  such  as  Novell  or 
VINES.  However,  there  are  several 
problems  with  this  approach.  First  of 
all,  you  could  not  allow  your  col¬ 
leagues  to  update  this  database.  If 
multiple  dBASE  programs  try  to 
simultaneously  update  the  same 
database  while  unaware  of  the 
activities  of  each  other,  a  scrambled 
database  will  result.  Another 
problem  is  that  it  may  be  inefficient 
to  have  dBASE  read  the  database 
across  the  network  as  it  searches  for 
records. 

An  alternative  approach  is  to  have  a 
“database  server”  on  the  network.  A 
user  would  specify  search  criteria  on 
his  personal  computer,  workstation, 
or  larger  machine,  which  would  send 
the  criteria  or  query  to  the  database 
server  via  the  network.  The  server, 
a  computer  with  the  only  copy  of  the 
database  and  a  database  program, 
then  initiates  the  search  using  its 
own  local  resources.  The  results  of 
the  search,  the  records  matching  the 
search  criteria,  are  then  sent  back  to 
the  user's  computer.  This  approach 
results  in  less  network  activity 
because  only  queries  and  their 
results  travel  across  the  network.  As 
well,  because  only  one  database 
program  is  actually  accessing  the 
database,  it  is  safe  to  give  many 
users  the  ability  to  do  updates. 

In  some  situations,  a  distributed 
database  is  better  suited  than  the 


centralized  database  server  dis¬ 
cussed  above.  For  example,  to 
create  a  database  of  all  research 
journals  and  books  in  Canada,  you 
might  use  multiple  database  servers, 
placing  one  in  every  Canadian 
university.  When  a  query  comes  in, 
the  database  servers  would  work 
together  to  provide  the  right  answer, 
even  if  this  requires  pulling  records 
from  the  servers  of  multiple  institu¬ 
tions. 

Database  servers  and  distributed 
databases  are  still  not  widely  used. 

In  fact,  there  are  few  examples  of 
networked  university  databases. 
However,  vendors  have  been 
promising  database  packages  which 
support  SQL,  a  standardized 
database  query  language.  It  is 
hoped  that  SQL,  which  stands  for 
Structured  Query  Language  and  is  a 
standard  way  for  computers  to  send 
queries  to  a  database  server,  will 
lead  to  more  networked  databases. 


Remote  Execution 

Remote  execution  allows  you  to  run 
a  program  on  a  remote  computer. 
This  can  be  useful  when  you  require 
the  resources  of  a  specialized 
computer,  such  as  the  CRAY  X-MP. 
Remote  execution  could  also  be 
used  to  distribute  the  load  of  work. 
For  example,  your  personal  com¬ 
puter  might  hand  some  work  to 
another  machine,  which  might 
otherwise  be  idle. 

Often,  you  do  not  need  to  learn  how 
to  use  another  computer  in  order  to 
use  remote  execution.  For  example, 
a  Mac  user  may  not  want  to  learn 
how  to  use  a  CRAY  X-MP,  though 
she  may  need  to  run  programs  on 
the  CRAY.  Remote  execution 
facilities  are  available  that  permit  the 
networked  Mac  user  to  request 
remote  execution  of  a  program  on  a 
networked  CRAY. 


One  of  the  most  common  remote 
execution  examples  on  campus  is 
the  use  of  the  UNIX  remote  shell 
facility.  An  UNIX  user,  using  a 
computer  connected  to  the  campus 
network,  can  run  any  UNIX  com¬ 
mand  on  another  UNIX  computer 
connected  to  the  network.  (The  user 
also  needs  authorization  to  use  both 
computers.) 


Remote  login 

Remote  login  permits  you  to  log  into 
and  use  another  computer  on  the 
network.  A  program  on  your  own 
computer  sends  the  characters  you 
type  to  the  remote  computer  and 
returns  information  from  that 
computer  to  your  screen.  People 
who  have  used  ProComm,  Kermit,  or 
Red  Ryder  from  their  personal 
computers  are  familiar  with  dialing 
up  and  using  a  remote  computer. 
This  type  of  activity  is  an  example  of 
a  simple,  two-computer  “network.”  A 
program  called  TELNET,  available 
for  practically  every  computer 
including  IBM  PCs,  Apple  Macin¬ 
toshes,  workstations,  and  mini  and 
mainframe  computers,  allows  people 
with  access  to  the  appropriate 
campus  network  to  log  into  other 
computers  on  the  network,  anywhere 
in  the  world.  In  this  way,  the 
potential  exists  for  a  user  to  log  into 
perhaps  thousands  of  computers. 

For  example,  using  TELNET  on  a 
Mac  that  is  connected  to  the 
University  of  Toronto’s  campus 
network,  it  is  possible  to  log  into  a 
computer  at  Stanford  University. 

There  are  several  reasons  why  you 
might  want  to  use  remote  login.  In 
some  cases,  remote  login  to  a 
computer  from  a  personal  computer 
or  workstation  is  a  cheap  alternative 
to  buying  a  dumb  terminal.  Also, 
using  the  network  may  be  cheaper 
than  running  a  dedicated  line  from 
the  terminal  or  computer  to  the 
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remote  computer.  Third,  because 
some  computer  users  need  access 
to  specialized  computers,  remote 
login  is  useful  because  it  permits 
easy  access  to  these  machines. 

Furthermore,  remote  access  may 
save  equipment  costs.  For  example, 
some  departments  are  using 
Macintosh  II  computers  as  file  and 
mail  servers  on  their  AppleTalk 
networks.  The  cost  of  a  graphics 
card  and  screen,  usually  about 
$2000,  can  be  saved  by  having 
maintenance  on  the  Mac  II  done 
using  a  product  called  Timbuktu. 
Timbuktu  permits  remote  login  to  the 
screenless  Mac  II  (i.e.,  the  file 
server)  from  another  Macintosh  on 
the  AppleTalk  network.  Timbuktu 
can  also  be  used  for  instructional  or 
other  purposes  between  two 
Macintoshes  that  have  screens. 


Printer  Sharing 

Printer  sharing  allows  access  to 
remote  printers  as  if  they  were 
directly  connected  to  your  computer, 
even  if  the  printer  is  connected  to 
another  computer.  For  example,  a 
dot  matrix  printer  may  be  connected 
to  one  personal  computer  in  your 
department.  Using  a  network  such 
as  Novell,  VINES,  or  IBM  LAN,  you 
can  make  the  printer  seem  as  if  it  is 
directly  connected  to  your  personal 
computer.  In  actual  fact,  your  print 
files  are  being  sent  from  your  PC  to 
the  computer  with  the  printer.  This 
computer  is  sometimes  called  a 
“print  server." 

Some  printers  can  be  attached 
directly  to  a  network.  For  example, 
an  Apple  LaserWriter  can  be  hooked 
to  an  AppleTalk  network  because 
the  LaserWriter  contains  the 
necessary  software  and  hardware  for 
AppleTalk  communication.  Macs  on 
the  AppleTalk  network  all  have  the 
appearance  of  direct  access  to  the 


LaserWriter.  However,  when  printing 
is  requested,  the  Mac  actually  uses 
the  AppleTalk  network  to  send  the 
file  to  the  LaserWriter. 

How  is  remote  printing  related  to 
other  network  services  already 
discussed?  In  many  cases,  remote 
printing  is  really  a  special  case  of  file 
transfer.  The  file  to  be  printed  is 
transferred  from  your  computer  to 
the  “print  server."  In  other  cases,  as 
when  “intelligent”  printers  such  as 
the  LaserWriter  are  involved,  remote 
printing  is  comparable  to  remote 
execution.  When  a  Macintosh  needs 
to  print,  it  actually  sends  the  printing 
request,  in  the  form  of  a  language 
called  PostScript,  to  the  LaserWriter 
for  remote  execution. 


Other  Equipment 
Sharing 

Engineering  departments  across 
Canada  are  saving  money  by  using 
e-mail  in  order  to  share  equipment 
needed  for  manufacturing.  Making  a 
small  number  of  prototypical  VLSI 
(Very  Large  Scale  Integration) 
electronic  chips  is  very  expensive. 
Engineering  departments  with  VLSI 
design  courses  cut  costs  by  e- 
mailing  designs  to  a  single  facility  at 
Queens  University.  There  a  small 
number  of  chips  are  produced,  each 
chip  containing  all  the  designs 
turned  in.  Each  university  then  uses 
only  that  part  of  the  chip  that  it 
designed.  By  combining  all  the 
designs  on  one  chip,  the  cost  of 
producing  the  chip  can  be  substan¬ 
tially  lowered. 

On  a  smaller  scale,  a  department 
might  save  money  by  sharing 
equipment  such  as  modems.  This 
sharing  will  work  as  long  as  the 
equipment  is  not  so  heavily  in 
demand  that  some  people  can’t  get 
the  opportunity  to  use  it.  A  modem 


such  as  the  Shiva  NetModem  can  be 
connected  to  an  AppleTalk  network. 
Then,  any  one  Mac  on  the  network 
can  use  it  at  a  given  time. 

As  these  examples  show,  not  only 
printers  can  be  shared  across  a 
network.  From  pen  plotters  to 
automated  lathes,  many  possibilities 
exist  for  sharing  equipment.  Equip¬ 
ment  sharing  is  really  another 
special  case  of  file  transfer  and 
remote  execution.  If  another 
university  has  an  automated  lathe 
that  you  wish  to  use  remotely,  you 
can  view  that  lathe  simply  as  another 
specialized  box  on  the  network. 
Similarly,  the  CRAY  X-MP  is  another 
box  with  a  speciality,  as  is  a  Laser¬ 
Writer,  which  has  printing  as  its 
speciality. 

The  New  View  of 
Computing 

At  one  time,  large  computers  were 
the  focus  of  computing,  while 
printers,  terminals,  disks,  and  so  on 
were  looked  upon  as  mere  peripher¬ 
als.  But  networks  have  changed  the 
perspective  on  computing.  The 
emerging  view  focuses  on  “comput¬ 
ing  boxes,"  each  of  which  performs 
specialized  functions,  that  are 
interconnected  through  a  network  to 
create  the  overall  computer  system. 
The  individual  user  interacts  with  the 
box  sitting  on  his  desk.  This,  in  turn, 
uses  the  network  connection  —  a 
single  cable  —  to  negotiate  among 
other  boxes. 
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Computer  communications  can  be 
compared  to  human  communica¬ 
tions.  Just  as  humans  must  speak 
the  same  language  in  order  to 
understand  each  other  well,  so 
computers  must  use  the  same 
protocols  in  order  to  exchange 
information.  When  connected 
computers  can  successfully  ex¬ 
change  information  by  using 
compatible  hardware  and  software 
protocols,  a  network  exists.  Unfortu¬ 
nately,  the  problem  of  diverse  and 
dissimilar  human  languages  also  has 
an  analogy  in  the  world  of  computer 
communications  —  there  are  many 
different  computer  network  protocols, 
and  most  of  them  are  incompatible. 

This  incompatibility  exists  because 
many  computer  vendors  have  their 
own  network  protocols.  IBM  has 
SNA,  Digital  has  DECNET,  Prime 
has  PRIMENET,  and  Wang  has 
WangNet.  In  the  personal  computer 
arena,  things  are  even  more 
confusing  because  there  are  so 
many  more  protocols.  Apple 
AppleTalk,  Corvus  Omninet  PC/ 
NOS,  IBM  PC  LAN,  Novel  NetWare, 
Torus  Systems  Tapestry,  3Com 
3+Share,  Sun  TOPS,  and  Banyan 
Systems  VINES  are  just  some  of  the 
network  types,  all  of  which  have 
some  representation  on  campus. 

Not  only  are  different  network 
protocols  largely  incompatible,  many 
network  protocols  don't  offer  the 
same  network  services.  For 


example,  one  might  offer  remote 
execution  while  another  might  not. 
Furthermore,  even  if  two  network 
protocols  offer  the  same  service, 
they  may  do  it  in  completely  different 
ways.  For  example,  Sun’s  NFS 
(network  file  system)  moves  files  a 
byte  at  a  time  from  the  file  server  as 
the  files  are  accessed  by  the  client. 
IBM  AFS,  on  the  other  hand,  created 
with  a  different  design  philosophy, 
sends  entire  files  from  the  file  server 
to  the  client  when  they  are  first 
accessed.  Incompatibility  is  so 
widespread  that  even  the  features 
and  format  of  a  service  as  simple  as 
e-mail  are  often  dissimilar. 

In  some  cases,  the  incompatibility  of 
network  protocols  in  the  marketplace 
may  not  matter,  as  in  a  corporation 
that  uses  a  single  vendor  for  all  its 
computing  needs.  In  most  places, 
however,  especially  in  universities, 
incompatibility  can  pose  a  real 
problem.  If  you  work  on  a  Digital 
VAX  computer  connected  through 
DECNET,  it  would  be  frustrating  to 
be  unable  to  exchange  e-mail  or 
share  resources  with  your  colleague 
at  another  university  who  happens  to 
use  an  IBM  mainframe.  An  even 
greater  problem  exists  where 
departments  on  campus  are  using 
more  than  one  network  protocol. 

This  causes  problems  when,  for 
example,  someone  in  the  depart¬ 
ment  on  an  IBM  PC  LAN  network 
wants  to  access  the  printer  con¬ 
nected  to  the  UNIX  machine,  which 
is  on  a  different  type  of  network. 


Gateways  to  Better 
Communications 

One  way  to  solve  this  interconnec¬ 
tion  problem  is  to  build  “gateways.” 
For  example,  UTCS  runs  a  gateway 
on  campus  for  moving  e-mail 
between  the  campus  DECNET  and 
other  campus  networks.  There  is 
also  an  e-mail  gateway  between  the 
campus  RSCS  network  and  other 
campus  networks.  (RSCS  is  an  IBM 
protocol  used  for  the  NetNorth/ 
BITNET/EARN  network.)  Because 
an  e-mail  gateway  is  dedicated 
exclusively  to  e-mail  service, 
services  such  as  file  transfer,  remote 
execution,  and  so  on  need  their  own 
gateways. 

However,  because  so  many  network 
protocols  are  used  in  universities, 
building  gateways  to  bridge  every 
possible  combination  of  protocols 
would  quickly  get  out  of  hand.  If  one 
“standard”  protocol  existed,  this 
might  provide  a  solution  to  the 
problem.  Then  we  could  either  use 
the  standard  protocol  or  build  a 
gateway  between  our  vendors’ 
proprietary  protocols  and  the 
standard  protocol.  Currently,  the 
closest  thing  to  a  standard  protocol 
is  the  Internet  protocol  suite,  more 
commonly  known  as  TCP/IP.  The 
development  of  TCP/IP  was  initiated 
by  DARPA  (Defense  Advanced 
Research  Projects  Agency)  in  the 
early  1970s,  when  its  system 
administrators  realized  that  the 
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American  military  needed  to  inter¬ 
connect  various  networks.  Today, 
TCP/IP  is  so  widespread,  especially 
within  North  American  research 
networks,  that  it  is  a  de  facto 
standard. 

Several  hundred  networks  using  the 
TCP/IP  protocol  suite  are  now 
interconnected.  In  the  United 
States,  these  include  the  following: 
ARPAnet,  which  connects  research 
institutions  funded  by  American 
Defense  contracts;  MILnet,  the 
American  Military  network  which 
used  to  be  part  of  ARPAnet;  CSNET, 
which  connects  North  American 
Computer  Science  departments;  and 
NSFNet,  which  connects  American 
National  Science  Foundation 
supercomputers.  These  networks 
cover  wide  areas  and  are  in  turn 
connected  to  many  regional  net¬ 
works,  some  of  which  cover  multiple 
States.  The  regional  networks,  in 
turn,  are  connected  to  campus 
networks,  which  are  connected  to 
departmental  networks. 

In  Canada,  a  national  TCP/IP 
research  network  has  yet  to  be 
created,  though  the  National 
Research  Council  (NRC)  is  now  ne¬ 
gotiating  for  the  establishment  of 
NRNet  (National  Research  Network). 
NRNet  is  envisaged  as  a  backbone 
network  connecting  regional 
networks.  It  is  felt  that  a  Canadian 
TCP/IP  network  would  encourage 
research  in  Canada  as  well  as 
prevent  the  redundancy  of  Canadian 
universities  running  individual 
network  connections  to  the  U.S.  in 
order  to  use  American  networks.  A 
few  TCP/IP  regional  networks 
already  exist  in  Canada.  In  Ontario 


we  have  ONet,  which  is  only  a  few 
months  old.  It  currently  connects  the 
U  of  T  and  six  universities  (soon  to 
be  seven  or  eight),  and  is  expanding 
to  include  two  provincial  centres  of 
excellence,  at  least  two  government 
departments,  and  four  industrial 
members.  A  cluster  of  new  mem¬ 
bers  in  Ottawa  will  soon  be  attached 
via  a  very  fast  Ottawa/Toronto  link. 

TCP/IP  networks  have  existed  for 
many  years  at  the  University  of 
Toronto.  Departments  such  as 
Computer  Science  and  Engineering 
were  using  TCP/IP  back  in  the  days 
when  it  was  largely  an  experimental 
protocol.  For  the  last  five  years, 
UTCS  has  been  building  and 
maintaining  a  TCP/IP  campus 
backbone  network.  Quite  a  few 
departments  with  a  departmental 
TCP/IP  network  connect  to  the 
overall  campus  network.  Fortunately 
for  the  computer  user,  these 
hundreds  of  networks  (campus  and 
international)  all  appear  as  a  single 
network.  This  collection  of  intercon¬ 
nected  TCP/IP  networks  is  frequently 
referred  to  as  the  “Internet.” 

Network  interconnectivity  will  permit 
people  to  use  a  number  of  services, 
including  one  called  TELNET.  If, 
when  using  TCP/IP,  you  issue  the 
command: 

telnet  watmath.waterloo.ca 

you  will  be  be  establishing  a  remote 
login  to  the  “watmath"  machine  at 
the  University  of  Waterloo.  Behind 
the  scenes,  invisible  to  you,  your 
departmental  network  is  passing 
information  to  the  campus  backbone 
network,  which,  in  turn,  is  talking  to 


the  ONet  network,  which  is  talking  to 
Waterloo's  network. 

TCP/IP  is  easy  to  use  and  has  many 
things  going  for  it.  Thanks  to  the 
many  TCP/IP  network  interconnec¬ 
tions,  a  researcher  at  this  university 
can  use  TCP/IP  to  reach  most  of  the 
research  institutions  of  North 
America.  TCP/IP  is  available  for 
most  types  of  computers,  so  there  is 
a  good  possibility  that  you  can 
communicate  and  share  resources 
with  your  research  colleagues  even 
if  they  use  a  different  computer  than 
yours.  Also,  because  this  and  other 
university  communities  have  years  of 
experience  using  TCP/IP,  there  is  a 
lot  of  expertise  to  draw  on  when 
problems  arise. 

TCP/IP  is  available  in  several  ways. 
In  some  cases,  there  are  public 
domain  implementations.  In  other 
cases,  vendors  offer  competing 
TCP/IP  products.  TCP/IP  is  used 
over  many  different  forms  of  physical 
media.  On  campus,  TCP/IP 
networks  use  optical  fibre  as  well  as 
different  types  of  cables.  TCP/IP 
can  even  be  run  over  radio  connec¬ 
tions. 


What  is  the  future 
of  TCP/IP? 

The  ISO  (International  Standards 
Organization)  is  working  on  a  new 
set  of  protocols  called  OSI,  which 
stands  for  “Open  Systems  Intercon¬ 
nect.”  The  experience  gained  by 
developing  TCP/IP  and  other 
network  protocols  is  being  used  to 
develop  this  new  suite  of  protocols. 
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Will  ISO/OSI  replace  TCP/IP?  Some 
authorities  running  TCP/IP-based 
networks  say  it  will,  while  other 
people  are  more  cautious  in  their 
predictions.  Dennis  Ferguson  of 
Mechanical  Engineering  at  U  of  T, 
whose  opinions  on  networking 
futures  are  widely  respected,  thinks 
we  will  not  see  a  quick  migration  to 
OSI,  even  though  many  people  talk 
about  it  happening.  He  believes  that 
people  will  be  running  both  OSI  and 
TCP/IP  on  the  same  networks  and 
machines  for  a  long  time.  He  does 
concede  that  OSI  will  eventually 
replace  TCP/IP,  but  only  as  applica¬ 
tions  running  under  OSI  become 
more  fully  featured.  He  explains  that 
there  is  some  confusion  in  the 
industry  —  people  are  holding  off 
purchasing  applications  for  TCP/IP 
because  they  fear  that  OSI  will  take 
over  and  render  their  software 
obsolete.  Dennis  contends  that 
people  need  not  fear,  for  TCP/IP  will 
be  useful  for  as  long  as  it  fills  the 
needs.  This  means  that  if  applica¬ 
tions  for  TCP/IP  fit  your  needs  now, 
then  TCP/IP  is  useful  to  you  —  you 
don't  need  OSI.  As  he  points  out  to 
those  waiting  for  OSI,  it  took  ten 
years  to  get  TCP/IP  right,  and  OSI  is 
a  lot  more  complex. 


Gateways  from  TCP/IP  to 
other  Network  Protocols 

Alex  Nishri 

nishri@gpu.  utcs.  utoronto.  ca 

D  ecause  the  TCP/IP  network  protocol  suite  is  a  de  facto  standard, 

D  people  using  a  different  network  protocol  would  like  to  know  how  to 
connect  to  TCP/IP.  In  many  cases,  it  is  possible  to  gateway  some 
services  from  your  network  to  TCP/IP  and  thus  enjoy  interconnectivity 
across  network  protocols. 

An  example  of  this  form  of  gateway  is  the  DECNET  e-mail  bridge  run  by 
UTCS.  This  bridge,  set  up  by  the  Communications  and  Technical 
Support  (CTS)  group  at  UTCS,  gateways  e-mail  between  the  Digital 
DECNET  campus  network,  used  by  Digital  VAX  computers,  and  the 
campus  TCP/IP  network.  Another  example  is  an  RSCS-to-TCP/IP  e-mail 
gateway  that  is  run  by  the  UTCS  Systems  Group.  (RSCS  is  the  network 
protocol  used  by  the  NetNorth/BITNET/EARN  network.)  In  another  case, 
the  Information  Centre  and  CTS  are  currently  working  on  an  AppleTalk- 
to-TCP/IP  e-mail  gateway.  Using  this  gateway  and  an  e-mail  package 
called  QuickMail,  Macintosh  users  will  be  able  to  communicate,  via  their 
AppleTalk  network,  with  TCP/IP  networks  and,  via  the  TCP/IP  networks, 
with  DECNET  and  RSCS  networks. 

The  result  of  these  e-mail  gateways  is  that  e-mail  can  be  exchanged  be¬ 
tween  any  machines  served  by  AppleTalk,  DECNET,  RSCS,  or  TCP/IP. 

It  also  means  that  e-mail  originating  from  or  directed  to  computers  on  any 
of  these  networks  can  use  the  international  network,  regardless  of  the 
protocol  used  by  the  international  network.  Note,  however,  that  only  e- 
mail  is  exchanged  across  the  gateways.  Other  network  services,  such  as 
file  transfer,  remote  login,  and  so  on,  are  not  supported. 

If  you  are  not  running  a  TCP/IP  protocol  network  but  you  need  to  connect 
to  one,  it  is  possible  to  run  TCP/IP  over  your  existing  network.  For 
example,  UTCS  has  an  AppleTalk  network  of  Apple  Macintosh  personal 
computers.  CTS  has  installed  a  box  between  the  campus  TCP/IP 
network  and  our  AppleTalk  system.  This  box,  called  a  Kinetics  FastPath, 
permits  us  to  run  TCP/IP  protocols  over  AppleTalk  protocols.  By  using  a 
public  domain  TCP/IP  TELNET  and  FTP  (file  transfer  protocol  —  written 
by  the  American  National  Center  for  Supercomputing  Applications), 
packets  of  information  are  sent  out  by  AppleTalk  using  TCP/IP  protocols. 
The  FastPath  box  removes  the  information  being  sent  to  the  TCP/IP 
network  from  the  AppleTalk  network  and  puts  this  information  on  the 
TCP/IP  network.  The  reverse  process  occurs  when  information  is 
directed  from  the  TCP/IP  network  to  a  Mac  on  AppleTalk.  Using  TCP/IP 
over  AppleTalk  provides  full  access  to  the  TCP/IP  network  through  the 
existing  AppleTalk  network. 
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Comparing  NetNorth  and  ONet 


Alex  Nlshri 

nishri@gpu.  utcs.  utoronto.  ca 


In  the  past  few  years,  Computer- 
News  has  featured  a  number  of 
articles  describing  NetNorth/BITNET/ 
EARN.  With  Dr.  Warren  Jackson’s 
announcement  last  month  in  Com- 
puterNews  that  the  campus  network 
is  now  connected  to  ONet,  some 
people  might  be  wondering  how  the 
two  networks  compare.  BITNET, 
which,  according  to  legend,  stands 
for  “Because  Its  There  NETwork,” 
was  created  in  1981 .  It  is  a  network 
that  connects,  primarily,  the  comput¬ 
ing  centres  of  American  universities. 
BITNET  was  modelled  on  one  of  the 
oldest  and  biggest  computer 
networks,  Vnet,  which  is  IBM’s 
internal  network. 

BITNET,  like  Vnet  before  it,  uses  the 
IBM  RSCS  protocol.  RSCS,  which 
stands  for  Remote  Spooling  Commu¬ 
nications  Subsystem,  is  the  IBM 
mainframe  operating  system  (VM) 
protocol  for  printing  remotely.  It  was 
designed  so  that  a  mainframe  user 
printing  a  file  could  route  it  through 
the  RSCS  network  to  the  preferred 
printer.  It  was  also  designed  so  that 
files  produced  by  card  readers 
(which  read  punch  cards  —  card¬ 
board  cards  with  holes  punched  in 
them  to  denote  data)  could  be  routed 
to  the  appropriate  computer. 

By  using  the  ability  of  RSCS  to  send 
printer  files  and  card  files  through 
the  network,  BITNET  permits  file 
transfer  between  IBM  mainframes. 
The  IBM  VM/CMS  SENDFILE 
command  is  used  to  break  up  a  file 
so  it  can  be  sent  as  a  card  file,  and 


the  RDRLIST  and  RECEIVE 
commands  are  used  to  put  the  file 
back  together.  IBM  also  supplies  a 
command  called  NOTE  for  sending 
electronic  mail  (e-mail).  Finally,  a 
command  called  TELL  is  supplied  to 
send  one-line  messages  to  the 
screen  of  someone  currently  logged 
into  a  computer  on  the  RSCS 
network. 

When  NetNorth,  originally  called 
OUNet  (Ontario  Universities  Net¬ 
work),  was  created  in  1984,  TCP/IP, 
RSCS,  and  other  protocols  were 
available.  One  of  the  early  goals  of 
NetNorth  was  to  connect  to  Ameri¬ 
can  research  networks,  and  both 
RSCS  (e.g.,  BITNET)  and  TCP/IP 
(e.g.,  ARPAnet)  were  available  for 
making  these  connections.  How¬ 
ever,  only  RSCS  was  considered  at 
the  time. 


NetNorth  Based  on 
RSCS 

NetNorth  was  modelled  on  BITNET. 
Money  was  scarce,  and  the  need  for 
a  researchers’  computer  network 
was  not  yet  well  established  in 
Canada.  Many  of  the  computing 
centres  at  universities  involved  in 
organizing  NetNorth  had  IBM 
mainframes  that  could  be  pressed 
into  service  at  little  additional  cost. 
As  well,  RSCS  works  well  over  slow 
communication  lines,  and  slow  lines 
(i.e.,  2400  baud)  had  been  chosen 
for  use  between  the  universities  in 
order  to  limit  costs. 


NetNorth  was  created  using  RSCS 
network  protocols.  NetNorth 
connected  to  BITNET,  the  American 
research  network  based  on  RSCS, 
and  EARN,  BITNET’s  EuroAsian 
equivalent,  and  has  served  Cana¬ 
dian  researchers  quite  well. 


RSCS  Versus 
TCP/IP 

How  does  an  RSCS  network  like 
NetNorth/BITNET/EARN  differ  from 
TCP/IP-based  networks  such  as 
ONet,  NYsernet,  ARPAnet,  NSFNet, 
and  so  on?  At  a  lower  level,  one 
basic  difference  is  that  RSCS  is  a 
“store  and  forward”  network  technol¬ 
ogy  whereas  TCP/IP  is  not.  For 
example,  when  you  send  e-mail  to 
Carleton  University  from  the  Univer¬ 
sity  of  Toronto  machine  called 
UTORVM,  the  file  queues  up  and  is 
then  transmitted  to  a  machine  at 
McGill  University  called  MCGILL1. 

At  MCGILL1 ,  the  file  is  stored  and 
queued  to  wait  for  a  line  to  a 
machine  at  Queen's  University  called 
QUEENS,  and  then  forwarded. 
Similarly,  QUEENS  stores  the  file, 
queues  it,  and  then  forwards  it  to  a 
machine  called  UOTTAWA.  UOT- 
TAWA  stores  and  then  forwards  it  to 
a  machine  called  CARLETON,  the 
intended  destination. 

A  TCP/IP  network  sending  the  same 
file,  on  the  other  hand,  would  break  it 
up  into  little  pieces  called  datagrams, 
which  are  sometimes  incorrectly 
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called  packets.  Each  o?  these  is 
usually  only  a  few  hundred  bytes  in 
size.  The  individual  datagrams  are 
routed  through  the  network  or 
networks  until  they  arrive  at  their 
destination.  Then  they  are  reas¬ 
sembled  in  their  correct  order  to  form 
the  final  file. 

At  a  higher  level,  there  are  more 
basic  differences,  and  these  are 
important  to  users.  RSCS  networks 
only  provide  e-mail  and  file  transfer. 
Because  of  the  store  and  forward 
nature  of  RSCS  networks,  they 
cannot  provide  services  such  as 
remote  login,  remote  execution  in 
real  time,  and  other  similar  services. 
Furthermore,  because  RSCS  is  a 
proprietary  protocol,  any  additional 
services  to  be  provided  through 
RSCS  would  almost  certainly  have  to 
be  provided  by  IBM. 

TCP/IP-based  networks  are  fre¬ 
quently  used  for  e-mail,  file  transfer, 


remote  login,  remote  execution, 
network  file  systems,  and  so  on. 
Because  TCP/IP  is  an  open  protocol, 
that  is,  the  specifications  are 
available  to  anyone,  and  because  it 
is  a  protocol  that  the  research 
community  continues  to  develop, 
new  network  services  are  being 
added.  In  fact,  unlike  RSCS,  it  is 
fairly  easy  for  an  applications 
programmer  to  write  software  that 
uses  the  underlying  layers  of  TCP/IP 
to  build  new  services.  For  example, 
a  time  synchronization  protocol, 
used  to  synchronize  the  time  clocks 
of  computers  across  the  network, 
was  recently  written  and  is  now 
supplied  with  some  UNIX  systems. 

What  is  the  future  of  RSCS  and 
TCP/IP  networks  in  Canada? 

Certain  universities  are  so  distant 
from  other  universities  that  the  faster 
communications  lines  necessary  for 
TCP/IP  are  prohibitively  expensive. 
Other  universities  have  had  a  slow 


growth  of  network  usage  and  cannot 
justify  the  added  expense  of  a  faster 
line.  These  universities  are  likely  to 
want  to  use  NetNorth's  RSCS-based 
technology  for  a  while  longer. 

Other  universities,  especially  the 
larger  universities  in  larger  popula¬ 
tion  centers,  are  connecting  to  the 
TCP/IP  international  networks. 

Thus,  they  are  paying  for  parallel 
TCP/IP  and  RSCS  network  connec¬ 
tions.  A  package  called  BITNET  II 
(which  is  supposed  to  be  available 
this  fall)  permits  RSCS  protocols  to 
run  over  a  TCP/IP  network.  Using 
this,  universities  connecting  to  TCP/ 
IP-based  regional  networks  would 
not  need  to  pay  for  parallel  lines. 
BITNET  II  will  also  permit  an  orderly 
migration  for  universities  moving 
from  RSCS  protocols  to  TCP/IP 
protocols.  The  ONet  network  is 
currently  looking  at  getting  BITNET 
II,  since  in  Ontario  we  are  still 
running  parallel  lines  for  NetNorth 
and  ONet. 


dBASE  IV  Update  Seminar 


Irene  Rosiecki 

roslecki(a)vm.  utcs.  utoronto.  ca 


We  have  scheduled  dBASE  IV 
Update  Seminars  for  dBASE  III  Plus 
users  who  would  like  to  see  the  new 
features  of  dBASE  IV.  These 
seminars  will  highlight  the  enhance¬ 
ments  and  additions  to  the  com¬ 
mands  and  functions  of  dBASE. 

We  are  offering  these  seminars 
because  so  many  new  features  have 


been  included  with  dBASE  IV.  A 
completely  new  user  interface  has 
been  added,  along  with  full  query-by¬ 
example  and  SQL  capability,  a  fully- 
featured  applications  generator,  and 
hundreds  of  improvements  in  the 
dBASE  command  language.  These 
changes  represent  major  advances 
in  the  ease-of-use  and  functionality 
of  dBASE. 


The  dates  and  times  of  the  seminars 
are  as  follows: 

•  Thursday,  April  20,  1989 
10:00-12:00  noon 

•  Wednesday,  May  3,  1989 
2:00-4:00  p.m. 

To  find  out  about  registration 
procedures  and  to  book  a  spot  in 
one  of  these  seminars,  please  call 
Irene  Rosiecki  at  978-4565. 
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Microcomputer  Courses 


Irene  Rosiecki 

rosiecki@vm.  utcs.  utoronto.  ca 


The  following  list  shows  courses  scheduled  from  April  through  to  June  only,  though  more  courses  are  scheduled  for 
July  and  August.  To  find  out  about  registration  procedures  and  to  book  a  place  in  any  of  these  courses,  please 
contact  Irene  Rosiecki  at  978-4565. 


Introduction  to  dBASE  ISi  Plus 

June  26-30,  1989 
9:00-12:00  noon 

dBASE  IV  for  the  Beginner 

May  29-June  2,  1989 
2:00-5:00  p.m. 

dBASE  8V  Update  Seminars 

April  20,  1989 
10:00-12:00  noon 

May  3,  1989 
2:00-4:00  p.m. 

Desktop  Publishing  Seminar 

April  18,  1989 
10:00-3:00  p.m. 

Introduction  to  DOS 

June  19-23,  1989 
9:00-1 1:00  a.m. 

Electronic  Mail  Seminar 

May  24,  1989 
2:00-3:30  p.m. 


HyperCard  Seminar 

June  19-20,  1989 
10:00-12:00  noon 

Microsoft  Word  on  the  Macintosh 

May  15-19,  1989 
1:00-5:00  (May  15) 

1:00-4:00  (May  16-19) 

Introduction  to  PageMaker  3.0 

April  24-28,  1989 
12:00-3:00  (April  24) 

1 :00-3:00  (April  25-28) 

ProComm  Communications 
Seminar 

May  24,  1989 
12:00-2:00  p.m. 

Introduction  to  Lotus  1-2-3 

May  15-19,  1989 
2:00-5:00  p.m. 

Introduction  to  SAS  on  the  PC 

April  24-28,  1989 
3:00-5:00  p.m. 


intermediate  Applications  of  SAS 
on  the  PC 

June  19-23,  1989 
2:00-5:00  p.m. 

Introduction  to  WordPerfect, 
Version  4.2 

April  24-28,  1989 
12:00-3:00  p.m. 

Introduction  to  WordPerfect, 
Version  5.0 

May  15-19,  1989 
9:00-12:00  noon 

Advanced  WordPerfect,  Version 

5.0 

June  5-9,  1989 
9:00-11:00  a.m. 

June  19-23,  1989 
11:00-1:00  p.m. 


June  5-9,  1989 
1:00-3:00  p.m. 
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Review:  Commodore  PC40-III  and  Packard 
Sell  PACKMATE  12 


Paul  Roth 

proth@vm.  utcs.  utoronto.  ca 


Two  new  AT-compatible  machines 
have  come  to  market  in  recent 
months.  Both  come  with  a  small 
footprint,  1  megabyte(MB)  of  RAM,  a 
40MB  hard  disk,  VGA  graphics,  and 
MS-DOS  3.3,  and  both  operate  at 
12MHz  and  offer  excellent  perform¬ 
ance  at  an  inexpensive  price. 


Commodore  PC40- 

fii 

The  Commodore  PC40-III  is  a 
speedy  machine.  Its  most  striking 
feature  is  the  speed  of  its  40MB  hard 
disk.  We  rate  it  at  20 
milliseconds(ms)  average  access 
time  with  a  data  transfer  rate  of  580 
kilobytes/second  (KB/sec),  which  is 
simply  outstanding  performance.  It 


Packard  Bell  PACKMATE  12 


is  fast  enough  for  a  1-1  interleave 
and  has  produced  no  drive  errors  in 
the  two  months  we  have  had  the 
machine. 

The  PC40  comes  with  25-pin  serial 
and  parallel  ports,  a  VGA  video  port 
with  clearly  labelled  DIP  switches  at 
the  rear  of  the  unit,  and  a  Commo¬ 
dore  mouse  port.  Note  that  a  VGA- 
compatible  monitor  is  necessary, 
such  as  VGA  mono,  VGA  colour,  or 
multisync.  The  built-in  graphics 
adapter  can  emulate  CGA,  HGC, 
EGA,  or  VGA.  The  standard 
configuration  is  for  a  VGA  mono 
monitor;  we  reviewed  it  with  a  VGA 
colour  monitor  (TTX). 

Documentation  comes  in  the  form  of 
an  Operations  Guide  and  an  MS- 
DOS  manual.  The  guide  is  very 
useful,  providing  necessary  technical 
specifications  as  well  as  enough  in¬ 
formation  for  the  beginning  user.  For 
instance,  its  discussion  of  which  kind 
of  80287  you  could  use  in  the  PC40 
is  uncommonly  lucid. 

The  PC40  worked  with  all  software 
and  hardware  that  we  tried  on  it. 

This  includes  desktop  publishing 
software  such  as  PageMaker,  word¬ 
processing  programs  such  as  Word 
and  WordPerfect,  and  many 
graphics  packages.  It  also  worked 
perfectly  well  with  our  DEST 
scanner  and  IBM  Token  Ring 
Network  adapter. 


The  PC40  does  sacrifice  a 
few  things  to  keep  the  price 
down.  Memory,  as  in  other  Com¬ 


modores,  excludes  parity  checking. 
The  processor  uses  one  wait  state. 
The  motherboard  is  partially  covered 
by  the  drive  bay  chassis,  making  it 
difficult  to  get  at.  However,  the  usual 
jumpers  that  you  might  need  to 
access  are  exposed.  There  are  only 
three  16-bit  slots  and  one  8-bit  slot 
available,  although  all  can  take  full- 
length  cards  and  all  are  empty:  the 
serial  port,  parallel  port,  graphics 
adapter,  and  floppy-disk  controller 
are  all  built-in  on  the  motherboard, 
and  the  hard  disk  controller  sits  on 
the  drive  itself. 

With  the  PC40,  Commodore  has 
pushed  the  AT  to  its  limits.  It  is  quite 
fast  and  represents  excellent  value 
for  the  price.  With  mouse  and  VGA 
monochrome  monitor,  it  costs 
between  $2800  and  $3000  at  the 
University  of  Toronto  Computer 
Shop.  It’s  an  excellent  buy. 


Packard  Bell 
PACKMATE  12 


We  have  had  the  Packard  Bell 
PACKMATE  12  for  a  much  shorter 
review  period  than  the  PC-40.  While 
we  have  not  fully  tested  it,  prelimi¬ 
nary  findings  indicate  that  it  slightly 
outperforms  the  PC-40  in  CPU 
speed  but  has  a  slower  hard  disk 
speed.  We  rate  the  Miniscribe  8051 
hard  disk  at  28  ms,  with  a  data 
transfer  rate  of  almost  400  KB/sec. 

It  is  possible  to  reduce  the  interleave 
to  provide  even  better  performance. 
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It  comes  with  one  parallel,  one  9-pin 
serial,  and  one  25-pin  serial  port. 

The  serial  port  worked  well  with 
ProComm  at  9600  baud  and  with 
LapLink  at  1 15  kilobaud.  A  bonus  is 
the  additional  9-to-25  pin  adapter 
included  with  the  machine. 

The  PACKMATE  12  uses  zero  wait 
states,  allows  for  2MB  of  RAM  on  the 
motherboard,  and  offers  one 
proprietary  slot  for  memory  expan¬ 
sion  for  a  total  of  up  to  8MB  of 
memory  meeting  the  LIM  4.0 
Expanded  Memory  Specification.  In 
all,  there  are  six  16-bit  slots  and  two 
8-bit  slots  in  addition  to  the  proprie¬ 


tary  slot,  with  the  serial/parallel  card, 
disk  controller,  and  VGA  adapter 
taking  up  one  slot  each.  All  software 
and  hardware  tested  thus  far  has 
worked  well,  including  an  IBM  Token 
Ring  board  running  PC  LAN. 

The  PACKMATE  12,  bundled  with 
IMSI  Publisher,  a  combination  word¬ 
processing  and  desktop  publishing 
package,  currently  sells  for  $2900 
with  a  monochrome  VGA  monitor 
and  $3200  with  VGA  colour.  It  is 
noteworthy  that  Packard  Bell’s 
reputation  on  campus  has  under¬ 
gone  changes  recently.  Their 
machines  are  widely  used  on 


campus,  and  until  late  1988,  the 
company  flourished  here.  Their  ATs, 
while  bulky,  are  well  respected;  ours 
still  continues  to  function  well.  Late 
last  year,  however,  delivery  prob¬ 
lems  arose,  causing  frustration  for 
many  parties.  Packard  Bell,  under 
the  leadership  of  a  new  vice- 
president  of  sales,  is  now  endeav¬ 
ouring  to  reestablish  itself  and 
promises  to  avoid  the  delivery  and 
quality  control  problems  it  experi¬ 
enced  last  year.  The  PACKMATE 
12  promotion  is,  we  hope,  a  step  in 
the  right  direction. 


L0CKIT:  Affordable  PC  Security 


Paul  Roth 

proth@  vm.  utcs.  utoronto.  ca 


If  your  PC  with  a  hard  disk  is  acces¬ 
sible  to  more  than  one  person,  you 
may  be  interested  in  LOCKIT  I,  II, 
and  III,  security  devices  from 
Security  Microsystems  Consultants. 

LOCKIT  I  is  the  first  level  of  defense. 
It  prevents  you  from  accessing  a 
hard  disk  unless  the  correct  pass¬ 
word  is  entered  when  the  system  is 
booted.  Booting  from  the  floppy 
drive  won't  defeat  the  security 
scheme  —  you  will  get  an  “invalid 
drive  specification"  message  if  you 
try  to  access  the  hard  disk.  A 
second  feature  allows  you  to  blank 
and  lock  the  keyboard  and  screen 
while  a  program  or  application  is 
running,  preventing  even  a  <Ctrl-Alt- 
Del>  input  sequence  from  affecting 
operations.  The  password  must  be 
entered  to  restore  normal  operation. 
We  found  this  feature  worked  well 
when  tested  with  several  common 
software  packages. 


LOCKIT  I,  which  uses  a  combination 
of  hardware  and  software  security,  is 
not  only  easy  to  install  and  use,  it 
also  seems  to  be  impregnable  —  we 
couldn’t  find  a  way  to  defeat  it.  Even 
a  program  such  as  Norton  Utilities 
cannot  be  used  against  LOCKIT  I  — 
if  you  don’t  know  the  password,  you 
cannot  access  the  hard  disk.  This 
package  would  be  ideal  in  a  public 
setting  where  only  authorized  users 
are  allowed  to  access  a  PC’s  hard 
disk. 

If  you  would  like  to  allocate  private 
subdirectories  on  the  hard  disk  for 
each  potential  user,  you  can  use 
LOCKIT  II.  This  allows  each  user  to 
create  a  private  password  for  access 
to  a  hidden  subdirectory.  While 
stopping  short  of  encryption,  this 
seems  to  provide  stringent  security 
in  a  multiuser  environment. 


LOCKIT  III  can  be  used  to  limit 
access  to  specific  applications  on 
the  disk.  You  act  as  the  LOCKIT 
administrator  to  assign  passwords 
and  access  controls  to  each  user 
and  generate  individual  menus  of 
authorized  applications.  LOCKIT  III 
can  also  be  used  as  a  batch  menu 
generator  for  people  unfamiliar  with 
(or  unhappy  with)  the  DOS  interface. 
These  features,  together  with  the 
ability  to  create  a  secure  system  and 
the  availability  of  optional  proprietary 
encryption/decryption,  make  this  an 
useful  package. 

LOCKIT  works  on  most  hard  disk 
systems.  If  you’re  concerned  about 
unauthorized  access,  consider  giving 
it  a  try.  Each  of  the  three  packages 
comes  with  a  short  manual  and  sells 
for  about  $80.  LOCKIT  I,  II,  and  III 
are  available  from  Torco  Systems. 
Call  Lee  Rector  at  (416)  285-6644. 
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PS30-C  Application  Generator 


Paul  Roth 

proth@vm.  utcs.  utoronto.  ca 


PRO-C  is  a  C  source  code  gen¬ 
erator.  Using  a  menu-driven 
approach,  you  can  build  data 
structures,  screens,  menus,  and 
reports,  complete  with  context- 
sensitive  Help,  to  form  applications. 
While  this  sounds  similar  to  the  front 
ends  and  report  generators  of  many 
database  packages,  the  extra  benefit 
is  that  in  each  of  the  above  cases,  C 
source  code  is  generated.  This  not 
only  allows  you  to  modify  the  source 
code  itself,  it  also  makes  the 
application  more  portable.  PRO-C 
has  versions  for  MS-DOS,  QNX, 
XENIX,  and  UNIX.  Thus,  if  appropri¬ 


ately  licensed,  code  can  be  easily 
moved  from  a  machine  running  DOS 
to  a  MicroVAX  or  Sun. 

In  any  of  the  environments,  a  C 
compiler  is  necessary  to  compile  the 
source.  Once  compiled,  the 
application  can  be  handed  to  a  user, 
who  will  not  need  to  have  a  compiler 
or  PRO-C.  PRO-C  is  thus  aimed  at 
applications  developers.  In  addition, 
it  can  be  used  for  teaching  C  itself. 

Interfaces  to  Btrieve,  ISAM,  and 
dBASE  III  Plus,  along  with  the  ability 
to  define  interfaces  to  other  pack¬ 


ages,  allow  construction  of  complete 
applications.  The  Btrieve  run-time 
module  is  included. 

UTCS  will  have  a  copy  of  PRO-C  for 
MS-DOS  for  evaluation  in  April.  If 
you  use  Turbo  C,  Microsoft  C, 
WATCOM  C,  or  Zortech  C,  you 
might  want  to  try  it  out.  Please  call 
978-HELP  to  arrange  an  appoint¬ 
ment.  PRO-C  for  MS-DOS  is 
available  from  Vestronix  in  Waterloo 
for  $405.  Call  Paul  Valeriote  at  1- 
800-265-2682. 


Harvard  Graphics  Now  at  UTCS 


Terry  Jones 
tj@vm.  utcs.  utoronto.  ca 


Harvard  Graphics  Version  2.1, 
one  of  the  most  popular 
graphics  programs  for  IBM  PC  and 
compatible  microcomputers,  is  now 
installed  in  the  UTCS  Microcomputer 
Lab.  It  can  be  used  to  create  35MM 
slides  (using  the  UTCS  Polaroid 
Pallette  slide  maker),  printed  graphs 
(laser  print  on  paper  or  transparen¬ 
cies),  or  video  slide  shows. 

The  program  is  an  easy-to-use 
menu-oriented  system.  It  works  well 
with  or  without  a  mouse  and 
supports  a  wide  variety  of  hardware, 
such  as  HP  LaserJet  printers,  film 
recorders  (slide  makers),  plotters, 
and  video  adapters  and  displays. 

Harvard  Graphics  makes  it  very  easy 
for  you  to  produce  word,  line,  bar, 


pie,  and  other  types  of  charts.  Data 
for  the  charts  can  be  entered  directly 
into  the  program  or  can  be  imported 
from  plain  text  (ASCII)  or  Lotus  1-2-3 
files.  The  program  can  be  configured 
for  two  printers,  one  film  recorder, 
and  one  plotter  at  the  same  time. 

For  example,  you  may  select  an 
inexpensive  colour  dot-matrix  printer, 
an  high-quality  black  and  white  laser 
printer,  a  plotter  (for  colour  drawings 
without  large  shaded  areas),  and  a 
film  recorder  (for  high-quality  35MM 
slides).  Once  created,  your  graphs 
and  charts  can  be  produced  on  any 
of  these  devices.  The  program  can 
also  export  in  many  forms.  For 
example,  you  can  export  charts  and 
graphs  in  EPS  (Encapsulated 
PostScript)  or  HPGL  (Hewlett 


Packard  Graphics  Language)  form 
for  use  in  a  desktop  publishing 
package. 

As  well  as  being  easy  to  use, 

Harvard  is  also  powerful.  The  menu 
system  is  almost  self  explanatory  — 
everything  you  need  is  available  on 
one  of  the  menus.  This  easy  but 
powerful  concept  applies  to  what  you 
create  as  well.  Harvard  makes  it  very 
easy  to  create  a  basic  chart,  then 
gives  you  the  power  to  customize 
the  chart  as  you  need. 

For  more  information  or  to  arrange  to 
see  Harvard  Graphics,  contact  Terry 
Jones  at  978-4924. 
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SAS/PC  News 


Table  1 


Calcomp  ColorMaster  thermal  printer 
Computer  Graphics  Metafile  (CGM),  black  and  white 
Computer  Graphics  Metafile  (CGM),  color 
QMS  Colorgrafix  100  printer  (CGM  format) 

QMS  Colorgrafix  100  printer;  A  size  paper  (CGM  format) 
Hewlett  Packard  DeskJet  Printer  (75  DPI) 

Hewlett  Packard  DeskJet  Printer  (100  DPI) 

Hewlett  Packard  DeskJet  Printer  (150  DPI) 

Hewlett  Packard  DeskJet  Printer  (300  DPI) 

Imagen  2308  printer,  non-quoted  binary  output 
Panasonic  KX-P1080i  dot  matrix  printer 
Panasonic  KX-Pl091i  dot  matrix  printer 
QMS  ColorScript  100  printer  (PostScript) 

Texas  Instruments  855  printer 
;  Encapsulated  PostScript  files  —  for  producing  thin  lines 


Andrzej  Plndor 
apindor@vm.  utcs.  utoronto.  ca 


SAS/PC  Renewal 

We  would  like  to  remind  all  our  SAS/ 
PC  licensees  that  the  current  license 
for  the  product  expires  on  June 
30,1989.  If  you  want  to  continue 
using  SAS/PC,  you  must  renew  the 
license.  That  is  the  “bad  news.”  The 
good  news  is  that,  thanks  to  the 
large  number  of  licensees,  the 
individual  costs  are  going  down.  We 
expect  the  following  fee  schedule  to 
apply  from  July  1 ,  1989: 


Basic  package 

(base  +  ST  AT  +  GRAPH):  $70 

SAS/FSP  $10 

SAS/IML  $20 

Basic  package  for  networks 
(for  each  machine)  $35 


We  will  send  letters  to  all  licensees 
in  the  near  future  to  detail  the 
renewal  procedure. 

Release  6.03  Up¬ 
dates 

We  have  received  an  update  for  the 
SAS/GRAPH  module.  The  update 
fixes  certain  problems  with  the 
GPLOT  procedure  and  with  some 
existing  drivers  (such  as  the  driver 
for  the  Hercules  card).  In  addition, 
the  update  provides  new  drivers  for 
the  devices  listed  in  Table  1. 


The  SAS  Institute  has  also  sent  us 
an  important  update  to  the  SAS/ 
STAT  module.  This  update  contains 
revisions  of  two  procedures  — 

PROC  GLM  and  PROC  LIFEREG  — 
as  well  as  five  procedures  new  to 
Release  6.03  of  SAS/STAT:  PROC 
CORRESP,  PROC  LIFETEST, 
PROC  PRINQUAL,  PROC  PROBIT, 
and  PROC  TRANSREG.  These 
procedures  are  described  in  SAS 
Technical  Report:  P-179,  which  you 
can  order  through  UTCS.  If  you  are 
only  interested  in  PROC  LIFETEST, 
you  can  use  the  Version  5  SAS/ 
STAT  manual. 

If  you  obtained  your  license  for  SAS/ 
PC  before  March  20,  1989  and  want 
to  add  the  updates  for  SAS/GRAPH 


and/or  SAS/STAT  to  your  system, 
please  call  978-4990  to  arrange  to 
borrow  the  update  diskettes. 

New  SAS/PC  mod¬ 
ule:  SAS/ETS 
(Econometrics  and 
Time  Series) 

We  have  received  a  beta  version  of 
the  newest  SAS/PC  module:  SAS/ 
ETS.  If  you  are  interested  in  trying  it 
out,  you  are  welcome  to  get  it  from 
UTCS  at  no  cost.  The  module  will 
work  until  the  renewal  deadline.  All 
we  ask  is  that  you  share  with  us  your 
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impressions  of  the  software  —  we 
will  send  users'  comments  to  the 
SAS  Institute. 

New  SAS/PC  mod¬ 
ule:  SAS/OR  (Op¬ 
erations  Research) 

SAS  Institute  will  soon  provide  a 
SAS/OR  module  for  microcomputers. 
Whether  UTCS  will  obtain  the 
license  for  this  module  depends  on 
the  number  of  interested  users.  If 
you  are  interested  in  acquiring  this 


module,  please  call  Andrzej  Pindor 
at  the  number  given  below. 

SAS/ASSIST: 
Menu-Driven  Inter¬ 
face  to  SAS/PC 

Licensed  users  of  SAS/PC  can 
obtain  a  SAS/ASSIST  module  from 
us  free  of  charge.  SAS/ASSIST  is  a 
component  product  of  base  SAS 
software  that  is  designed  to  give 
quick  and  easy  access  to  many 
features  of  the  SAS  System. 


SAS  under  UNIX 


Andrzej  Pindor 
apindor@  vm.  utcs.  utoronto.  ca 


Since  1988,  the  SAS  system 
has  been  available  for  several 
computers  operating  under  UNIX, 
specifically  the  Sun  (SunOS  4.0)  and 
HP  (HP-UX)  workstations.  Because 
of  the  large  number  of  these 
machines  at  the  University  of 
Toronto  (Suns  in  particular),  UTCS 
has  acquired  a  site  license  for  SAS 
under  UNIX,  and  we  are  ready  to 
distribute  it  to  interested  parties.  As 
usual  with  SAS,  this  is  a  yearly 
license  and  it  covers  the  following 
single-user  workstations: 

HP  9000/318;  HP  9000/320;  HP 
9000/319; 

Sun  3/50  series;  Sun  3/60  series; 
Sun  3/100  series;  Sun  3/200  series 


The  following  machines  are  consid¬ 
ered  to  be  multiuser  machines  and 
are  counted,  for  the  purpose  of  the 
license  fee,  as  10  workstations  each: 


HP  9000/330;  HP  9000/350;  HP 
9000/360;  HP  9000/370; 

Sun  3/100  Sunserver;  Sun  3/200 
Sunserver 


The  license  period  begins  July  1, 
1989  and  we  expect  the  following 
fees  to  apply: 

Base  SAS  and  SAS/STAT : 

$100  for  single-user  machines 
$400  for  multiuser  machines 

Additional  modules  (SAS/GRAPH, 
SAS/FSP,  and  SAS/IML): 


However,  to  be  able  to  use  SAS/ 
ASSIST,  you  must  have  at  least 
1MB  of  expanded  memory  (LIM  3.0 
EMS  or  later). 


Who  To  Contact 

If  you  are  having  problems  running 
SAS/GRAPH  that  might  relate  to  the 
above  mentioned  fixes,  or  if  you 
need  any  of  the  new  drivers  or  are 
interested  in  acquiring  any  of  the 
new  modules,  please  contact 
Andrzej  Pindor  at  978-5045. 


$50  each  for  single-user  machines 
$200  each  for  multiuser  machines 

For  people  wanting  to  install  SAS  as 
soon  as  possible,  that  is,  in  April  or 
May,  the  prices  will  be  50%  of  the 
prices  given  above,  and  of  course, 
the  license  has  to  be  renewed  on 
July  1,  1989. 

Please  note  that  large  HP  machines 
not  listed  above  (such  as  the  HP 
9000/850)  are  not  covered  by  the 
site  license.  SAS  Institute  will  only 
license  machines  of  this  size 
individually. 

Please  call  Andrzej  Pindor  at  978- 
5045  if  you  are  interested  in  install¬ 
ing  SAS  on  your  UNIX  machine. 
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Features  of  SAS/IML  on  a  Microcomputer 


Bill  Fehlner 


Overview 

As  mentioned  in  the  October  1988 
issue  of  ComputerNews ,  SAS/IML 
(Interactive  Matrix  Language)  is  now 
available  as  part  of  the  University  of 
Toronto  site  license  for  SAS/PC. 
Although  IML  is  primarily  a  matrix 
manipulation  language,  it  also  has  a 
graphics  component  and  it  interfaces 
quite  well  with  other  elements  of  the 
SAS  system.  This  article  is  an 
introduction  to  some  of  the  facilities 
available  through  IML. 

For  many  years,  the  SAS  system 
has  included  PROC  MATRIX,  the 
ancestor  of  the  current  PROC  IML. 
PROC  MATRIX  had  a  number  of  the 
basic  features  of  the  prototype 
matrix  language,  APL,  but  because 
PROC  MATRIX  lacked  some  key 
elements,  it  easily  frustrated 
programmers  used  to  working  in  a 
richer  environment.  IML  has 
overcome  many  of  these  limitations, 
and  it  is  relatively  easy  to  express 
matrices  and  parallel  operations  on 
matrices  in  a  concise  and  natural 
form. 


Matrix  Language 

Those  readers  who  are  familiar  with 
matrix  languages  can  skip  the  first 
two  paragraphs  in  this  section.  One 
of  the  major  benefits  of  a  matrix 
language  is  the  ability  to  quickly 
prototype  an  idea  in  a  form  very 
close  to  the  way  you  think  about  the 
problem.  Being  interactive,  it  is  easy 
to  build  a  complex  calculation  one 
step  at  a  time,  checking  each  step 
for  validity.  Moreover,  an  unfamiliar 


operator  or  function  can  be  quickly 
tested  in  a  number  of  situations  to 
verify  its  correct  behaviour. 

Using  a  matrix  language  has 
parallels  to  programming  for  a 
supercomputer  —  you  have  to  force 
yourself  to  think  in  different  terms  if 
you  are  to  take  advantage  of  the 
latent  power  of  the  language.  In 
particular,  a  good  matrix  language 
such  as  IML  allows  you  to  replace 
most  iterative  (i.e.,  do  loop)  proc¬ 
esses  by  one  or  more  operations  on 
matrices.  This  has  benefits  even  for 
small  matrices  (e.g.,  5x5)  and 
provides  enormous  gains  as  the  size 
of  the  matrices  increase. 

Two-dimensional  (n  x  m)  matrices 
form  the  basis  for  computations  in 


IML.  Vectors  (n  x  1),  scalars  (1  x  1), 
and  empty  matrices  (0  x  0)  are 
special  cases.  Matrices  can  be 
assigned  values  directly  or  can  be 
extracted  from  either  a  SAS  dataset 
or  a  raw  data  set.  New  matrices  can 
be  built  from  one  or  more  old 
matrices  in  many  ways.  A  few 
examples  are  seen  in  Table  1. 

There  are  many  more  arithmetic, 
comparison,  and  logical  operators 
available.  These  are  extended  even 
further  by  functions  for  reshaping, 
matrix  inquiry,  reduction,  linear 
algebra,  and  so  on.  Some  examples 
are  seen  in  Table  2. 

All  of  the  scalar  functions  available  in 
a  SAS  DATA  step  can  be  accessed 
from  within  IML.  In  particular,  values 


Table  2 


Table  1 


Ml  ||M2 

concatenate  horizontally 

M3//M4 

concatenate  vertically 

M5  +  M6 

add  element  by  element 

M7<M8 

compare  element  by  element 

Ml  #M6 

multiply  element  by  element 

M3  *  M5 

matrix  multiplication 

M7[,5] 

extract  the  fifth  column  of  M7  as  a  column  vector 

M8(+,] 

calculate  the  column  sums  ot  M8  as  a  row  vector 

M9‘ 

transpose  the  matrix 

REPEAT(M5,2,3) 

combine  six  copies  of  M5,  two  vertically  and  three 

ilWIMliSlIllllSIll 

horizontally 

NROW(M7) 

determine  the  number  of  rows  in  M7 

SSQ(M3) 

calculate  the  sum  of  squares  of  the  elements  of  M3 

INV(M6) 

calculate  the  inverse  of  a  square  matrix  M6 
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of  various  probability  distributions  or 
their  inverses  (e.g.,  the  non-central  F 
distribution)  are  directly  accessible. 
This  collection  of  operators  and 
functions  provides  a  basis  for 
expressing  algorithms  in  a  very 
concise  form. 


An  Example 

For  example,  in  a  recent  project  it 
was  necessary  to  orthogonalize  a 
matrix,  X,  constructed  from  powers 
of  a  variable.  The  following  code 
creates  a  column  vector  of  variable 
values  and  column  vectors  repre¬ 
senting  its  powers: 

XI  ={1,2,6,11,26,51,76,101}  ; 

X2  =  XI  #  XI  ; 

X3  =  XI  #  X2  ; 

X4  =  X2  #  X2  ; 

A  column  of  the  orthogonal  matrix,  Z, 
can  be  computed  from  the  columns 
already  obtained  and  the  next  power 
vector.  For  example,  if  Z3  is  the 
column  generated  from  X3,  we  add 
Z3  to  Z  with: 

Z  =  Z||Z3  ; 

Then  we  can  calculate  the  column 
Z4  and  add  it  using: 

Z4  =  (1(8)  -  Z*INV(Z‘*Z)*Z‘)*X4  ; 

Z  =  Z||Z4  ; 

where  1(8)  is  the  identity  matrix, 
INV(...)  computes  the  matrix  inverse, 
and  Z‘  is  the  transpose  of  Z.  These 
few  lines  of  code  replicate  almost 
exactly  the  algorithm  as  expressed 
in  a  statistics  text. 


Modules  and  Their 
Storage 

Modules  are  a  named  collection  of 
SAS/IML  statements  that  are 
compiled  together  and  that  can  then 
be  referenced  by  name  at  any  later 
point  in  an  IML  session.  They  have 
some  analogy  to  subroutines  and 
provide  an  excellent  way  to  capture 
code  that  you  have  developed  and 
tested  in  an  interactive  session.  It  is 
as  simple  as  recalling  the  code  that 
just  ran  successfully,  adding  a 
START  and  a  FINISH  statement  to 
the  code,  and  submitting  it. 

Version  6.03  of  SAS/IML  has  added 
the  ability  to  create  libraries  of  these 
modules.  This  means  that  the  time- 
consuming  compile  need  only  be 
done  once.  A  later  session  can 
begin  by  naming  the  module  library 
and  loading  the  modules  of  interest 
into  the  workspace.  If  a  better 
version  of  a  module  is  created,  it  can 
be  added  to  the  library  at  any  time. 

It  is  possible  to  create  an  entire 
application  in  a  module  library.  Then 
you  need  only  supply  the  input  data 
as  vectors  and/or  matrices  and  call 
the  application. 

Interface  With 
Other  Components 
of  SAS 


The  interface  between  IML  and  base 
SAS  has  several  components.  One 
or  more  existing  SAS  data  sets  can 
be  opened  for  access  from  within 
IML,  and  new  SAS  data  sets  can  be 


created.  It  is  possible  to  convert  all 
or  part  of  a  SAS  data  set  into  a 
matrix  in  IML  with  a  single  IML 
READ  command.  Conversely,  a 
SAS  data  set  can  be  created  directly 
from  an  IML  matrix.  Individual 
records  in  a  SAS  data  set  can  be 
altered,  or  additional  records  can  be 
appended. 

As  was  mentioned  above,  all  of  the 
scalar  functions  available  in  a  SAS 
data  step  are  accessible  from  IML. 

IML  includes  a  facility  to  build  new 
IML  statements  from  within  IML. 

This  provides  considerable  flexibility 
in  building  applications  for  which 
some  items  (e.g.,  an  input  data  set 
name)  are  known  only  at  run-time. 
Operating  system  commands,  as 
well  as  display  manager  commands, 
can  be  issued  from  within  IML.  In 
generating  text  that  is  to  be  later 
executed,  both  the  character 
manipulation  functions  in  IML  and 
the  facilities  of  the  macro  language 
may  be  used. 

Interface  With 
Graphics 

IML  has  a  set  of  graphics  commands 
that  can  be  used  to  create  graphics 
images  one  piece  at  a  time.  IML 
graphics  operators  depend  on 
components  of  SAS/GRAPH,  and 
the  latter  must  be  installed  in  order  to 
use  these  operators.  The  graphics 
commands  also  require  considerable 
memory,  so  working  in  DOS  with 
EMS  or  in  an  UNIX  environment  is 
recommended. 
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The  graphics  commands  allow  you 
to  build  one  or  more  graphics 
segments  and  to  display  them  in  one 
or  more  viewports.  These  viewports 
are  predefined  areas  on  the  graphics 
device  and,  with  care,  one  can 
overlay  segments,  mask  certain 
areas,  and  change  the  scale  of  any 
segment.  Graphics  segments 
produced  by  SAS/GRAPH  proce¬ 
dures  and  stored  in  a  graphics 
catalog  can  also  be  displayed  in  a 
viewport.  Segments  produced  within 
IML  can  also  be  stored  in  a  catalog. 

IML  graphics  is  not  a  “paint"  style 
graphics  package.  Although  you 
have  the  benefit  of  the  rapid  display 
of  each  segment  as  it  is  being  built, 
you  must  work  in  terms  of  Cartesian 
coordinate  systems.  In  some  of  our 
initial  tests  of  the  graphics  com¬ 
mands,  we  found  it  difficult  at  times 
to  combine  segments  in  exactly  the 
form  desired. 

The  other  features  of  IML  are  much 
more  important  than  the  graphics 
commands,  although  the  presence 
of  these  commands  offers  the 
promise  of  better  things  to  come.  In 
the  meantime,  there  may  well  be 
applications  that  can  profit  from 
having  a  graphics  interface  immedi¬ 
ately  available  from  within  IML. 


Limitations 

There  are  a  number  of  limitations 
that  can  make  working  with  SAS/IML 
frustrating  at  times.  Some  of  these 
are  directly  related  to  the  hardware 


platform  being  used,  while  other 
limitations  are  a  result  of  design 
decisions. 

The  key  limitation  is  the  maximum 
number  of  elements  in  a  matrix.  For 
MS-DOS,  this  number  is  4095 
numeric  elements  or  32000  charac¬ 
ter  elements.  For  UNIX-based 
systems,  the  maximum  number  of 
either  type  of  element  is  increased  to 
32765.  Many  problems  can  be 
stated  in  terms  of  matrices  of  this 
size,  but  we  have  found  that 
intermediate  constructs  may  exceed 
the  limit.  It  is  sometimes  possible  to 
choose  an  alternative  solution  that 
uses  smaller  intermediate  matrices, 
but  at  other  times,  we  are  forced  to 
do  a  large  calculation  in  several 
segments.  This  takes  a  lot  of  time, 
both  because  the  IML  program  is 
further  from  the  natural  expression  of 
the  solution,  and  because  more 
checking  is  required  to  validate  the 
results. 

Another  limitation  is  that  arrays  can 
have  only  two  dimensions.  Once 
you  begin  to  think  in  terms  of  matrix 
operations  instead  of  do  loops, 
intermediate  constructs  involving  a 
third  dimension  will  sometimes  allow 
efficient  removal  of  yet  another  level 
of  looping.  There  are  also  mathe¬ 
matical  situations  that  are  most 
naturally  expressed  in  arrays  of  three 
or  more  dimensions. 

On  a  PC  with  DOS,  the  640  kilobyte 
(KB)  limit  imposed  by  the  operating 
system  means  that  the  IML  work¬ 
space  is  limited  to  about  100KB. 


This  becomes  a  problem  when  you 
work  with  a  large  number  of  IML 
modules  at  the  same  time.  You  can 
work  around  this  problem  in  several 
ways.  Modules  can  be  stored  in  a 
library  until  needed,  then  copied  into 
the  workspace  and  dropped  when  no 
longer  required.  Alternatively,  the 
addition  of  one  megabyte  of  ex¬ 
panded  memory  (EMS)  increases 
the  maximum  workspace  size  to 
350KB.  You  can  also  decide  to 
make  the  jump  to  a  UNIX  system  — 
then  the  workspace  size  is  limited 
only  by  the  size  of  your  machine,  not 
by  the  operating  system. 


An  Invitation 

SAS/IML  can  be  added  to  an 
existing  license  for  SAS/PC  or  it  can 
be  included  when  a  new  license  for 
SAS/PC  is  obtained.  In  either  case, 
please  contact  the  Information 
Centre  at  978-4990  for  registration 
forms.  If  you  would  like  to  discuss 
IML  further  or  see  a  demonstration  of 
the  product,  please  call  Andrzej 
Pindor  at  978-5045. 
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Mathematical  A  Review 


Andrzej  Pindor 

apindor@  vm.  utcs.  utoronto.  ca 


Bill  Fehlner 


ecently,  we  had  the  opportu¬ 
nity  to  evaluate  Mathematica  on 
an  Apple  Macintosh  II.  This  review 
gave  us  a  very  favourable  impres¬ 
sion  of  the  product,  demonstrating 
that  Mathematica  is  an  extensive 
package  that  incorporates  the 
functions  of  many  other  languages 
and  packages  into  a  single  inte¬ 
grated  framework.  As  well,  many  of 
the  limits  which  you  might  expect  to 
have  to  work  around  in  a  numerical 
package  have  been  removed.  This 
article  shares  some  of  our  experi¬ 
ences  with  Mathematica. 

While  our  copy  of  the  package  was 
for  the  Mac  II,  Mathematica  is  also 
available  for  Sun  workstations  —  we 
expect  to  have  it  installed  on  a  Sun 
3-60  in  the  Statistical  Numerical 
Analysis  Computation  office  at  UTCS 
in  the  near  future.  Mathematica  will 
also  be  available  for  the  NeXT 
computer  in  a  few  months.  In  fact,  it 
will  be  included  as  part  of  the 
standard  software  shipped  with  the 
NeXT. 

A  number  of  important  components 
of  Mathematica  are  listed  in  Table  1. 
Although  this  is  not  an  exhaustive 
list,  it  is  representative  of  the  power 
of  the  package. 

A  primary  component  of  Mathe¬ 
matica  is  the  Kernel.  The  Kernel  is 
essentially  the  same  for  all  imple¬ 
mentations  of  the  package  and  does 


all  of  the  processing  of  commands. 
The  syntax  of  commands  and  many 
detailed  examples  are  provided  in  a 
700-page  manual  (which  reads  more 
like  a  good  textbook). 


The  front  end  is  unique  to  each 
implementation  of  Mathematica.  The 
Macintosh  front  end  takes  very  good 
advantage  of  the  Macintosh  environ¬ 
ment.  For  someone  familiar  with  this 


•  algebraic  manipulation  including: 

-  symbolic  differentiation 

-  symbolic  integration 

-  expansion  and  reduction  of  expressions 

-  symbolic  matrix  algebra 

•  matrix  language  (reminiscent  of  APL) 

•  numerical  evaluation  of  expressions  including: 

-  integration 

-  differentiation 

•  extensive  special  function  library 

•  workspace  library  with  programs  for  particular  application  areas 

•  ability  to  program  in  several  forms: 

-  calculator  mode 

-  high  level  procedural  (similar  to  C) 

-  matrix  language  (similar  to  APL) 

-  access  to  the  LISP-like  structures  around  which  Mathematica  is 
organized 

•  ability  to  make  user  extensions  or  modifications  to  built-in  procedures 

•  arbitrary  precision  for  numeric  calculations 

-  integers  of  any  length 

-  operations  on  rational  numbers  done  exactly 

-  precision  for  real  numbers  can  be  set  at  any  time 

•  graphics  utilities 

-  two-dimensional  plots 

-  three-dimensional  plots 

-  animation 


Table  1 
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Figure  1 
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environment,  the  20-page  explana¬ 
tion  of  this  particular  front  end  is 
more  than  adequate.  All  user 
commands  and  Mathematica 
responses  are  retained  in  the  active 
document  as  you  work  and  are 
accessible  at  any  time  by  scrolling. 
Mathematica  documents,  called 
notebooks,  are  built  of  cells  which 
can  contain  text,  graphics  or 
Mathematica  expressions.  These 
cells  are  organized  hierarchically. 
Selecting  a  cell  or  group  of  cells  for 
further  processing  is  easy.  The 
characteristics  of  cells  can  be 
changed  at  any  time  using  a  pull¬ 
down  menu.  For  example,  any  cell 
or  group  of  cells  can  be  displayed  or 
closed,  which  makes  exploring  the 
contents  of  a  large  notebook  very 
easy  because  you  can  keep  the 
unwanted  information  from  cluttering 
the  screen  display.  You  have  to  try 
this  feature  to  really  appreciate  its 
convenience.  A  portion  of  the  online 
documentation  that  comes  with  the 
package  is  presented  in  the  form  of 
notebooks. 

Mathematica  has  a  number  of  ways 
of  displaying  and  storing  information. 
The  input  format  is  a  linemode 
expression  in  the  Mathematica 
language  (see  the  top  expression  in 
Figure  1).  Display  format  is  a 
disappointing  typewriter  style 
display  of  equations  (as  shown  in  the 
second  expression  in  Figure  1).  It  is 
possible  to  convert  expressions  to 
the  Te.X  equation  format  (see  the 
bottom  expression  in  Figure  1).  The 
final  formatted  version  produced  by 
TeX  is  quite  acceptable,  but  this 
does  nothing  to  reduce  frustrations 
when  working  with  complex  expres¬ 
sions  interactively.  Expressions  can 
also  be  displayed  or  stored  as 
Pascal  or  FORTRAN  code,  thus 


providing  a  fairly  direct  connection 
between  Mathematica  and  these 
languages. 

The  graphics  interface  is  quite  good. 
Graphics  are  stored  as  PostScript 
code  and  can  be  directly  printed  on  a 
laser  printer.  It  is  also  possible  to 
generate  a  set  of  related  graphs  and 
then  request  that  they  be  displayed 
in  sequence.  It  is  time  consuming  to 
produce  this  form  of  animation,  but 
the  results  are  very  effective. 

Mathematica  is  a  memory-hungry 
package.  Although  it  can  be 
installed  on  a  Mac  SE  with  2 
megabytes  (MB)  of  memory,  you 
won’t  be  able  to  do  too  much  with 
the  package.  The  Mac  II  that  we 
used  had  8MB  of  memory,  which  is 
the  amount  recommended  by  the 
developers  for  use  with  Mathe¬ 
matica.  We  noticed  that  the  mem¬ 
ory-use  indicator  often  rose  to  6MB 
for  moderately  complex  requests. 

For  a  group  with  several  machines 


linked  by  a  network,  it  is  possible  to 
have  the  Kernel  running  on  a  large 
machine  (e.g.,  a  Mac  II),  with  smaller 
front  ends  (e.g.,  Mac  SEs)  accessing 
this  Kernel  remotely.  We  have  not 
yet  had  an  opportunity  to  evaluate 
this  configuration. 


Problems 

In  using  Mathematica,  we  discov¬ 
ered  a  number  of  problems.  The 
most  critical  bug  showed  up  in  the 
way  Mathematica  saves  and 
restores  user-created  functions.  An 
algebraic  expression  was  altered  by 
Mathematica  in  a  subtle,  difficult-to- 
locate  manner  while  going  through 
the  storing  and  retrieving  process. 
Fortunately,  in  our  situation  the 
restored  function  gave  clearly 
incorrect  values,  but  the  problem 
could  be  overlooked  in  other  cases. 
To  test  the  technical  support 
provided,  we  reported  this  bug  to  the 
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HfCS  Oatapac  Access 
to  End 


developers.  They  were  able  to  find  a 
fix,  and  it  will  be  included  in  version 
1 .2,  due  for  release  at  the  end  of 
March. 

Our  frustrations  with  the  screen 
display  format  of  algebraic  expres¬ 
sions  was  discussed  above.  The 
surprising  ways  in  which  symbolic 
manipulations  were  carried  out  on 
occasion  were  another  source  of 
frustration.  For  example,  the 
indefinite  integral  of: 

(a2  -  x2)3'2 

was  efficiently  done,  but  the  attempt 
to  evaluate  the  indefinite  integral  of: 

(a2  -  x2)5/2 

was  a  disaster.  Both  of  these 
integrals  are  in  books  of  integrals 
and  can  be  done  by  hand.  Mathe- 
matica’s  symbolic  expression 
reduction  is  powerful,  but  it  some¬ 
times  needs  considerable  direction 
by  the  user.  In  general,  there  seems 
to  be  a  large  step  between  the  use 
of  simple  features  of  Mathematica 
and  access  to  the  sophisticated 
abilities  of  the  package. 

We  expect  that  Mathematica  will 
meet  the  needs  of  a  wide  range  of 
users.  More  people  are  now  gaining 
access  to  powerful  workstations  on 
either  a  shared  or  standalone  basis. 
Mathematica  delivers  the  features  of 
several  other  standalone  packages 
in  a  single,  integrated  environment. 

If  you  would  like  to  discuss  Mathe¬ 
matica  further  or  see  a  demonstra¬ 
tion  of  it  on  a  SUN  3-60,  please  call 
Andrzej  Pindor  at  978-5045. 


Ron  Vander  Kraats 
rvk@vm.  utes.  utoronto.  ca 


With  the  advent  of  networks  such  as  NetNorth,  ONet,  and 
BITNET,  the  UTCS  Datapac  Access  Facility  has  received  little 
use  over  the  past  year.  Therefore,  UTCS  decided  to  end  this 
service  in  March.  With  the  networks  that  are  currently  in  place, 
alternative  paths  exist  to  satisfy  most  needs.  Call  Advising 
Services  at  978-HELP  to  discuss  the  options  available. 


UTCS  Dial-In  Facilities 


Marvin  Wahlstrom 
marvin@gpu.  utes.  utoronto.  ca 


Because  of  the  decline  in  usage  of  the  300  bits-per-second  line 
(978-6200),  this  line  will  be  discontinued  as  a  separate  service. 
As  of  May  1,  1989,  UTCS  dial-in  facilities  can  be  accessed  by 
phone  at  978-3959  (300  and  1200  bps)  and  978-7239  (2400 
bps).  This  service  will  be  available  for  testing  as  of  April  10, 
1989. 
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University  Fiscal  Year-End 


Marg  Doherty 

doherty@vm.  utcs.  utoronto.  ca 


Users  are  reminded  that  the  University  Fiscal  Year-End  is  April  30,  1989.  This  means  that  all  blanket  orders  (Encum¬ 
brance  Memos)  raised  for  computing  on  a  Departmental  Appropriation  Account  (Ledger  1)  will  expire  with  the 
approach  of  that  date. 

The  Comptroller’s  Office  has  given  UTCS  a  billing  close-off  date  of  April  24,  1989,  for  charges  to  blanket  orders. 
Therefore,  the  last  day  for  accruing  charges,  to  be  applied  to  the  blanket  order,  is  April  21 ,  1989.  Charges  for  the 
remaining  few  days  of  April  (April  22  through  30  at  5:00  p.m.)  will  be  billed  in  May. 

In  order  to  achieve  uninterrupted  service  over  the  year-end,  account  administrators  are  advised  to  do  the  following: 

1 .  Supply  the  Accounting  Services  Office  with  a  blanket  order  (Encumbrance  Memo)  for  the  new  budget  year  by  April 
15,  1989.  It  should  clearly  show  the  CAN  (Customer  Account  Number)  holder’s  name,  the  CAN  number,  the 
dollar  amount,  and  the  1988/89  Encumbrance  Memo  number  that  it  is  replacing.  In  the  case  of  a  new  account, 
where  the  CAN  and  previous  Encumbrance  Memo  numbers  are  not  available,  “NEW  ACCOUNT”  should  be 
indicated. 

2.  Service  Access  Codes  (SACs)  should  be  checked  to  determine  whether  they  are  required  in  the  new  year.  If  they 
are,  the  expiry  date  should  be  checked  and  changed  if  necessary.  Spending  limits  are  another  important  consid¬ 
eration.  If  total  spending  limit  and  usage  to  date  require  changes,  this  information  should  also  be  communicated 
before  the  end  of  April. 

The  discussion  thus  far  has  dealt  mainly  with  the  year-end  situation  as  it  normally  affects  instructional  and  administra¬ 
tive  users.  Researchers  are  also  affected  by  the  expiration  of  departmental  subsidy  blanket  orders. 

Account  administrators  are  encouraged  to  discuss  any  doubts  or  difficulties  arising  with  accounts  or  access  codes  at 
anytime  by  calling  the  Accounting  Services  Office  at  978-7148. 

Mail  should  be  addressed  as  follows: 

UTCS  Accounting  Services 
4  Bancroft  Avenue,  Room  100B 
University  of  Toronto 

If  you  prefer  to  pay  us  a  visit,  we  are  at  this  address  from  9:00  a.m.  to  5.00  p.m.,  Monday  through  Friday. 
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Documents  at  UTCS 


'  '  '  ■  (  . 

All  vendor-produced  documentation  may  be  ordered  through  the  UTCS  Information  Office ,  Room 

201,  4  Bancroft  Avenue.  UTCS  documents  and  selected  vendor  documents  are  also  stocked 
there  for  purchase.  For  more  information  on  prices,  call  Dale  Wright  at  978-4990.  Whenever 
feasible,  documents  are  made  available  online,  and  users  are  encouraged  to  print  their  own 
copies.  On  the  VM  machine,  a  special  command  has  been  provided  for  this  purpose. 

To  print  online  documents  on: 

IBM  VM/CMS  OP  UNIX 

Type  “help  document”  Use  ipr  command 


The  following  examples  relate  to  the  table  below.  The  document  to  be  printed  is  the  UTCS  Guide 
to  Census  Tapes,  called  CENSUS  LISTING  on  CMS  and /usr/doc/utcs/census  on  GP  UNIX. 
<RETURN>  means  RETURN  or  ENTER  key. 

CMS:  document  <RETURN>  <RETURN> 

laser  census  listing  (forms  yxle  <RETURN> 

GP  UNIX:  nohup  ipr  -8p  -fyxle  / usr/doc/utcs/census  &  <RETURN> 


UTCS  Documents  in  hardcopy 


New: 

Previously  announced: 

UTCS  Catalogue:  Statistics  Products 
UTCS  Catalogue:  Text  Products 
UTCS  Guide  to  Census  Tapes 
UTCS  Guide  to  Kermit 
UTCS  Guide  to  Micro  File  Transfer  Service 
UTCS  Guide  to  Text  Processing  on  GP  UNIX 


Academic's  Guide  to  Microcomputer  Systems 

Character  Sets  for  Highspeed  Printing 

UTCS  GUIDE  TO  PRODUCTS  AND  SERVICES:  Introduction 

UTCS  GUIDE  TO  PRODUCTS  AND  SERVICES:  Basics 

UTCS  GUIDE  TO  PRODUCTS  AND  SERVICES:  Accounting 

UTCS  Catalogue:  Numerical  Products 


UTCS  Documents  online 


New: 


CMS 

LISTING 


GP  UNIX 


Forms 

Code 


Previously  announced: 


UTCS  GUIDE  TO  PRODUCTS  AND  SERVICES:  Introduction 
UTCS  GUIDE  TO  PRODUCTS  AND  SERVICES:  Basics 
UTCS  Catalogue:  Access,  Part  1 
UTCS  Catalogue:  Access,  Part  2 
UTCS  Catalogue:  Numerical  Products 
Product-Function  List 
UTCS  Catalogue:  Statistics  Products 
Product-Function  List 
UTCS  Catalogue:  Text  Products 
UTCS  Guide  to  BMDP 
UTCS  Guide  to  Census  Tapes 
Recipes  for  Using  Tapes  on  VM/CMS 
UTCS  Guide  to  FORTRAN  on  VM/CMS 
UTCS  Guide  to  GP  UNIX 
UTCS  Guide  to  Highspeed  Printing 


INTRO 

BASICS 

ACCESS1 

NUMCAT 

NUMLIST 

STATCAT 

STATLIST 

TEXTCAT 

BMDP 

CENSUS 

QUIKTAPE 

FORTRAN 

PRINT 


/usr/doc/utcs/intro 

/usr/doc/utcs/basics 

/usr/doc/utcs/accessl 

/usr/doc/utcs/access2 


/usr/doc/utcs/textcat 

/usr/doc/utcs/census 

/usr/doc/utcs/gpunix 

/usr/doc/utcs/print 


BXQD 

BXQD 

* 


*  Recommended  forms  code  for  the  8700  is  YXLE  unless  otherwise  stated, 
t  Use  the  87set  command.  Type  “help  87set". 
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Documents  continued 


UTCS  Documents  online  continued 


CMS 

GP  UNIX 

Forms 

LISTING 

Code 

UTCS  Guide  to  Kermit 

KERMIT 

/usr/doc/utcs/kermit 

. 

UTCS  Guide  to  Micro  Laser  Printing  Service 

MICRLASR 

UTCS  Guide  to  SAS 

SAS 

UTCS  Guide  to  SCRIBE 

SCRIBE 

(For  printing  instructions,  see  page  1  of  document) 

UTCS  Guide  to  Series/1  Terminal  Use 

SERIES 

3270  Emulation: 

Cybernex  APL100  and  Volker  Craig  VC404 

CYBER 

DM1520 

DM1520 

Hardcopy  Terminal 

HARDCOPY 

IBM  3101 

IBM3101 

* 

IBM  PC  Kermit 

PCKERMIT 

* 

SOROC  IQ 

SOROC 

* 

VT52 

VT52 

VT100 

VT100 

UTCS  Guide  to  SPSS 

SPSS 

UTCS  Guide  to  Text  Processing  on  GP  UNIX 

/usr/doc/utcs/text 

YXOG 

UTCS  Guide  to  TFW.MAK  in  SCRIBE 

TFWMAK 

• 

UTCS  Guide  to  VM/CMS 

CMSGD 

* 

UTCS  Guide  to  WSCRIPT 

WSCRIPT 

UTCS  Rate  Schedule  (Commercial) 

RATESCOM 

t 

UTCS  Rate  Schedule  (External) 

RATESEXT 

t 

UTCS  Rate  Schedule  (Internal) 

RATESINT 

t 

Other  Documentation  online 

Electronic  Mail 

A  User’s  Guide  to  Electronic  MAIL 

MAILBOOK 

YXOC 

Kermit 

Kermit  Protocol  Manual 

KERMITPM 

YXOE 

Kermit  User  Guide 

KERMITUG 

YXOF 

ProComm 

ProComm  Reference  Manual 

PROCOMM 

YXOE 

VM BATCH  Documents 

VMBATCH  User’s  Guide 

VMBATCH 

YXOA 

VMBATCH  Messages  and  Codes 

VMBATMC 

YXOA 

VMSECURE 

VMSECURE  User's  Guide 

VMSECURE 

YXOE 

VM  Tape  Documents 

TapeMap  User’s  Guide  and  Reference 

TAPEMAP 

* 

VMTAPE  Messages  and  Codes 

VMTMSGS 

YXOE 

VMTAPE  User’s  Guide 

VMTUSER 

YXOE 

Waterloo  SCRIPT 

Reference  Manual 

WSCRPTRF 

YXLC 

User’s  Guide 

WSCRPTUG 

YXLC 

Using  SCRIPT  in  MVS/TSO 

WSCRPTSO 

YXLC 

Waterloo  SCRIPT  and  a  PostScript  Printer 

WSCRPTPS 

YXLC 

Formula  Processor  Summary 

WSCRPTFP 

YXLC 

GML  User’s  Guide 

GMLUG 

YXLC 

GML  Reference  Summary 

GMLRFSUM 

YXLC 

*  Recommended  forms  code  for  the  8700  is  YXLE  unless  otherwise  stated, 
t  Use  the  87set  command.  Type  “ help  87set". 
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Consulting  and  Enquiries 


Applications  Support  &  Advising  Supervisor 

Alex  Nishri 

BC214 

978-7109 

External  Marketing  Consultant 

Ihor  Prociuk 

BC217 

978-6875 

Erindale  College 

Joe  Lim 

ER2035 

828-5311 

Information  Office 

Dale  Wright 

BC201 

978-4990 

Account  &  Access  Code  Enquiries) 

Sylvia  May 

BC101B 

978-7148 

IBM  PC  Maintenance 

Kam  Mark 

BC103 

978-5050 

Tape  Library  (Academic  Services) 

Susan  Kovago 

MP368 

978-7319 

Tape  Library  (Administrative  Services) 

Miranda  Fong 

MP368 

978-6693 

Terminal  Service 

Rosi  Tseu 

BC105 

978-7087 

UTCS  Noncredit  Short  Courses 

Irene  Rosiecki 

BC217 

978-4565 

Consulting  &  Advising  Services: . 978-HELP 

CMS,  and  GP  UNIX  userids: . ADVISOR 

CMS  Userid  for  mail  problems: . POSTMSTR 

System  Status  Enquiries  (GP  UNIX) . 978-4318 

System  Status  Enquiries  (IBM)  . 978-7393 

Interactive  Services  300  (bps) . 978-6200 

Interactive  Services  1200  (bps) . 978-3959 

Interactive  Services  2400  (bps) . 978-7239 


UTCS  Directory 


Director: 

Dr.  Warren  Jackson 

BC118 

978-8948 

wcj@vm.utcs.utoronto.ca 

Associate  Director: 

Eugene  Siciunas 

BC116 

978-5058 

eugene@vm.utcs.utoronto.ca 

Managers: 

Communications  STechnical  Support 

Norman  Housley 

BC121B 

978-4967 

norman@vm.utcs.utoronto.ca 

Information  Centre 

Don  Gibson 

BC217 

978-7331 

don@vm.utcs.utoronto.ca 

Internal  Systems  Support 

Ron  Vander  Kraats 

BC121A 

978-4428 

rvk@vm.utcs.utoronto.ca 

Operations  Support 

Dr.  Bob  Chambers 

MP350 

978-7092 

Systems  Support 

Bill  Lauriston 

MP331 

978-3579 

bill@vm.utcs.utoronto.ca 

Committees  on  Computing 


Committee  on  Administrative  Computing 
UTCS  Board 

Supercomputer  Users'  Group  at  U  of  T 
Research  Board  Standing  Committee 
on  Computing 


Chair 

Janice  Oliver 

978-4322 

Chair 

Prof  J.F.  Keffer 

978-4984 

Chair 

Prof.  J.M.  Ting 

978-4971 

Chair 

Prof.  C.C.  Gotlieb 

978-2986 

Legend 

BC  =  Bancroft  Building 
ER  =  Erindale 

MP  =  McLennan  Physical  Labs 
*  NetNorth/BITNET  EARN 
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UTCS  Terminal  and  Advising  Sites 


Names  and  Locations 


Central  Advising  Office  (CAO),  978-HELP 

Engineering  Annex  (EA,  CDF),  11  King’s  College  Road,  Rooms  103,  107,  107B,  201, 203 

Erindale  College  (Erin),  828-5339,  Mississauga  Road,  Erindale  Campus,  Rooms  2037,  2039A-B-C,  2045 

Robarts,  Robarts  Library,  130  St.  George  St.,  Room  1061 A 

Sidney  Smith  (Sidney),  100  St.  George  St.,  Rooms  1071,  2105 

St.Michael’s  College,  121  St.  Joseph  St.,  Room  107 

Trinity  College,  6  Hoskins  Ave.,  Room  024 

Victoria  University,  73  Queens  Park  Cres.,  Room  208 


Access  Hours 


Sites 

Hours  of  Access 

Restrictions* 

Advising 

Mon-Thurs  Fri 

Sat 

Sun 

CAO 

10:00-18:00 

10:00-18:00 

closed 

closed 

Research 

978-HELP 

CDF 

24  hrs 

24  hrs 

24  hrs 

24  hrs 

Undergrads 

No 

EA 

24  hrs 

24  hrs 

24  hrs 

24  hrs 

None 

978-HELP  for  Research 

Erin  (2039)A 

9:00-17:00 

9:00-17:00 

12:00-16:00 

12:00-16:00 

Research 

Rm  2005 

(2045-46-47) 

24  hrs 

24  hrs 

24  hrs 

24  hrs 

Undergrads 

Rm  2005 

(235)t 

8:00-22:00 

8:00-17:00 

closed 

closed 

None 

Rm  2046 

Robarts 

8:30-24:00 

8:30-24:00 

9:00-22:00 

13:00-22:00 

None 

978-HELP  tor  Research 

Sidney 

7:00-24:00 

7:00-24:00 

7:00-24:00 

7:00-24:00 

None 

978-HELP  for  Research 

St. Michael’s 

24  hrs 

24  hrs 

24  hrs 

24  hrs 

None 

978-HELP  for  Research 

Trinity 

8:00-22:00 

8:00-22:00 

8:00-22:00 

8:00-22:00 

None 

978-HELP  for  Research 

Victoria 

8:30-21:00 

8:30-21:00 

8:00-13:00 

8:00-13:00 

None 

978-HELP  for  Research 

Sites 

Advising 

Hours 

CAO 

Monday  through  Friday,  10:00  -  18:00 

Erin 

Monday  through  Friday,  09:00  -  22:00 

Legend 

I 

*  Research  includes  graduates,  faculty,  staff. 
\  Key  access  available, 
t  Access  restricted  to  building  hours. 


Terminal  and  Printer  Access 


Sites  PACX  Network  Printers  CDF/PC 

Terminal  Terminals 

Server 


CDF 

EA 

Erin 

Robarts 

Sidney 

St.Michael’s 

Trinity 

Victoria 

(Y=yes,  N=no) 

*  CDF/PC  only 


N 

Y 

Y 

Y 

Y 

Y 

Y 

Y 


N 

N 

Y 

N 

N 

N 

N 

N 


Y 

Y 

Y 

Y 

Y 

Y 
Y* 
Y* 


N 

N 

N 

Y 

Y 

Y 

Y 

Y 
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UTCS  Services 


UTCS  Centrally  Owned  and  Managed 


Systems 

IBM  V M/C  MS 

•  General  Purpose  Timesharing;  access  to  NetNorth,  BITNET,  and  EARN 
networks;  access  to  CRAY  X-MP/22 

•  4381  P02  processor,  16  megabytes  of  memory 

•  CP  operating  system,  VM/SP  HPO  R4.2 

•  CMS  timesharing  system,  VM/SP  Release  4 

•  RSCS  spooling  system.  Release  3 

•  CRAY  station  Release  4 

GP  UNIX 

Technical  Assistance;  978-8853 

•  General  Purpose  Timesharing  under  SUN  UNIX  3.2 

•  SUN  3/280,  8  megabytes  of  memory 

•  access  to  Linotronic  typesetter 

•  otters  a  sophisticated  and  powerful  environment  tor  text  processing 

•  otters  a  sophisticated  programming  environment  suitable  for  commercial 
software  development  or  testing 

•  full  access  to  USENET,  an  electronic  technical  information  exchange  facility 

•  offers  excellent  electronic  mail  facilities  and  ability  to  send  or  receive  mail 
from  most  computer  networks  worldwide,  such  as  UUCPNET,  ARPANET, 
NetNorth,  BITNET,  CSNET,  CDNNET 


Services 

Communications  &  Technical  Support 

Primary  Phones:  978-3787,  978-4967 

•  Communications  Group  provides  communications  systems,  terminals, 
modems,  data  channels:  consulting  and  installation. 

•  Field  Service  Group  installs  and  maintains  communications  and  computer 
systems,  particularly  IBM  PCs,  Micro  Vaxes,  and  Macintoshes,  on  a  contract 
basis  or  on  a  cost-per-call  basis. 

•  provides  consulting  on  computer  systems  technology  and  installs  computer 
systems 

•  provides  access  between  the  IBM  systems  and  machines  using  UNIX,  VMS 
and  other  operating  systems.  Ethernet,  Pronet,  and  IBM  TRN  technologies 
are  used  over  various  transmission  media  including  optical  fibre.  More  basic 
communications  techniques  are  also  used  for  moderate  speed  links. 

■  provides  consulting  on  local  area  networking  and  installs  LANS 

•  provides  access  to  NetNorth  (BITNET),  the  North  American  Universities 
Network;  ONET,  the  Ontario  Regional  Network;  and  USENET,  the  UNIX 
networking  fraternity 

•  provides  gateway  to  the  US  Internet 

•  will  provide  a  communications  solution  to  department  needs  on  a  contractual 
basis 

Information  Centre 

Primary  Phone;  978-HELP 

•  Provides  assistance  in  use  of  electronic  messaging,  including  use  of  Local 
Area  Networks  (LANS);  NetNorth/BITNET/EARN,  the  world  Universities 
network;  CDNNET,  the  Canadian  X.400  network;  ARPANET;  CSNET; 
USENET;  and  other  international  connections. 

•  provides  advising,  consulting  and  documentation  on: 

-  command  languages,  including  CMS  and  UNIX 

-  high  level  languages,  including  FORTRAN,  and  PL/I 

-  packages  and  libraries,  including  SAS,  SPSS-X,  BMDP,  IMSL,  and  NAg 

-  editors  and  formatters,  including  XEDIT,  ed,  nroff/troff 

•  provides  general  micro  support 

-  selection  consulting  for  hardware  and  software 

-  Micro  Lab  for  evaluation  of  hardware  and  software 

-  advice  on  University  discounts 

-  media  conversion  and  data  transfer 

-  operates  UTCS  Microcomputer  Bulletin  Board  System 

-  offers  Micro  Laser  Printing  Service 

-  offers  35mm  slide  production  service  using  Polaroid  Palette 

-  administers  Local  Area  Network  of  PCs  for  Education  Facility 

-  administers  Macintosh  Education  Facility 

•  high  quality  typesetting 

•  installs  and  maintains  application  packages 

•  provides  short  courses  and  seminars  on  the  more  popular  services  and 
software  packages 


The  principal  mandate  of  UTCS  is  to 
plan,  implement,  and  operate 
facilities  and  "common-carrier" 
networks,  and  to  plan  and  support 
divisional,  departmental  or  project 
computer  facilities  as  requested. 


Facilities  Managed  by  UTCS 


Administrative  Computing 

•  administrative  IMS/VS,  DB/DC,  DB2,  Batch,  and  TSO 

•  4381 -R1 4  processor,  32  megabytes  of  memory 

•  MVS  operating  system 

Computer  Disciplines  Facility/UNiX 

SUN  3/280s,  8  megabytes  of  memory  (zero.cdf) 

•  Computer  Science  interactive  access 

•  SUN  UNIX  3.5 

SUN  3/280s,  16  megabytes  of  memory  (one.cdf) 

•  Computer  Science  interactive  access 

•  SUN  UNIX  3.5 

Computer  Disciplines  Facility/PC 

•  97  Tl  Professional  Computers  connected  in  a  Local  Area  Network 

•  introductory  Computer  Science  instruction 

•  MS-DOS  with  Turing  environment 

Erindale  College  Systems 

VAX  8200,  8  megabytes  of  memory 

•  instructional  access  using  VMS 

•  research  access 

VAX-1 1/750,  5  megabytes  of  memory 
■  instructional  access  using  UNIX  (Berkeley  UNIX  4.3BSD) 

Institutional  Relations  System 

VAX- 1 1/750,  8  megabytes  of  memory 

•  database  sen/ices  to  the  owner  departments  using  VMS 

ERAS  Facility 

•  4361  -5  processor,  1 6  megabytes  of  memory 

•  general  VM/CMS  services  to  the  owner  departments 

Ontario  Centre  for  Large  Scale  Computation  (OCLSC) 

•  Cray  Research  Inc.  X-MP/24 

•  2  processors,  4  megawords  main  memory 

•  solid  state  disk  (SSD)  with  64  megawords  of  storage 

•  COS  1.17  operating  system 

•  VAX  8350  +  MicroVAX  II  and  VAX750  provide 
VMS  front-end  services 
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Software  List 


SOFTWARE  LIST 
for 

MICROCOMPUTERS 


The  following  are 
microcomputer  soft¬ 
ware  packages  for 
which  UTCS  can 
provide  either  support 
or  some  information. 
)4s  with  mainframe ' 
products,  micro 
packages  receive  'full 
support  (Class  A), 
limited  support  (Class 
B),  or  no  active 
support  (Class  C).  ' 
The  specific  criteria 
differ  from  those  for 
mainframe  classes  ' 
and  are  outlined  in  the 
Academics  Guide  to 
Microcomputer 
Systems. 
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Package/Compiler  Version  Environment  Support 

Application  Development  Tools 


BASIC 

GW  BASIC 

C 

Microsoft  C 
MPW  C 

WATCOM  C  &  Express  C 

FORTRAN 

IBM  FORTRAN/2 
Language  Systems  FORTRAN 
Microsoft  FORTRAN 
WATCOM  WATFOR-77 

Pascal 

MPW  Pascal 
TURBO  Pascal 

Tools 

ResEdit 

HyperCard 

Macintosh  Programmer’s  Workshop 
WATCOM  GKS 

Communications 

File  Transfer  &  Terminal  Emulators 
Kermit 
Kermit 
Kermit 
Kermit 

Lap-Link  DeskLink 
Lap-Link  Mac 
Lap-Link  PC 
MacTerminal 
PC  TALK3 
PC  PLOT  III 
ProComm 
Red  Ryder 

Network  Systems 
AppleShare 

Novell  Advanced  Netware 

STARLAN 

TOPS 

TOPS 

Network  System  Utilities 
lnter*Poll 

Database  Managers 

4th  Dimension 

AskSam 

Clipper 

DATAEASE 

dBASE  II 

dBASE  III  Plus 

FoxBASE 

Notebook  II 

REFLEX 

ZylNDEX 

Desktop  Publishing 

PageMaker 

PageMaker 


— 

MS-DOS 

5.1 

MS-DOS 

2.0.2 

Macintosh 

6.0 

MS-DOS 

1.0 

MS-DOS  3.3  &  OS/2 

1.0 

Macintosh 

4.0 

MS-DOS 

3.0 

MS-DOS 

2.0.2 

Macintosh 

— 

MS-DOS 

1.2d0 

Macintosh 

1.2.1 

Macintosh 

2.0.2 

Macintosh 

1.3 

MS-DOS 

0.8(35) 

Macintosh 

2.30 

MS-DOS 

— 

Apple  II  DOS 

— 

CP/M 

1.0 

MS-DOS 

1.2 

Macintosh 

2.16 

MS-DOS 

2.2 

Macintosh 

— 

MS-DOS 

— 

MS-DOS 

TU  2.4.2 

MS-DOS 

10.3 

Macintosh 

2.0.1 

Macintosh 

2.0a 

MS-DOS 

MS-DOS 

2T) 

Macintosh 

2.0 

MS-DOS 

1.0 

Macintosh 

Int.  1.03 

Macintosh 

3.0 

MS-DOS 

S87 

MS-DOS 

2.5 

MS-DOS 

— 

CP/M 

1.1 

MS-DOS 

2.1 4u 

MS-DOS 

2.03 

MS-DOS 

— 

MS-DOS 

— 

MS-DOS 

3.01 

Macintosh 

3.0 

MS-DOS 

B 
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Software  List  continued 


Package/Compiler 

Version 

Environment 

Support 

Ready  Set  Go 

4.0 

Macintosh 

C 

Ventura 

2.0 

MS-DOS 

B 

XPress 

1.0 

Macintosh 

C 

Electronic  Mail 

Microsoft  Mail 

1.36 

Macintosh 

B 

QuickMail 

1.0 

Macintosh 

B 

Graohics 

Charting 

35mm  Express 

4.02 

MS-DOS 

B 

Cricket  Graph 

1.2 

Macintosh 

C 

Freelance  Plus 

2.01 

MS-DOS 

B 

Harvard  Graphics 

2.1 

MS-DOS 

B 

Lotus  1-2-3 

2.01a 

MS-DOS 

B 

Microsoft  Excel 

1.5 

Macintosh 

B 

Microsoft  Excel 

2.0 

MS-DOS 

B 

SigmaPlot 

— 

MS-DOS 

C 

Draw  and  CAD 

Aldus  Freehand 

1.0 

Macintosh 

B 

Cricket  Draw 

1.1 

Macintosh 

C 

Generic  CADD 

3.0 

MS-DOS 

C 

MiniCad 

4.05 

Macintosh 

C 

Illustrator 

1.0 

Macintosh 

B 

lllustrator88 

1.6 

Macintosh 

B 

MacDraft 

1.2b 

Macintosh 

C 

MacDraw 

1.95 

Macintosh 

A 

MacDraw  II 

I.OvI 

Macintosh 

B 

Windows  Draw 

1.02 

MS-DOS 

C 

Image  and  Scanning 

ImageStudio 

1.05 

Macintosh 

B 

Publish  Pac 

2.0 

Macintosh 

B 

Publish  Pac 

2.1 

MS-DOS 

B 

Text  Pac 

2.0 

MS-DOS 

B 

Paint 

DR  HALO 

1.23 

MS-DOS 

C 

MacPaint 

2.0 

Macintosh 

A 

Microsoft  Paintbrush 

2.0 

MS-DOS 

C 

PC  Paintbrush 

2.5 

MS-DOS 

C 

SuperPaint 

1.1 

Macintosh 

B 

Windows  Paint 

2.03 

MS-DOS 

C 

Plotting  Subroutines 

WATCOM  GKS 

1.3 

MS-DOS 

B 

Numerical 

Derive 

1.14 

MS-DOS 

C 

Eispack 

n/a 

MS-DOS 

C 

Eureka 

n/a 

MS-DOS 

c 

GAUSS 

2.0 

MS-DOS 

B 

IMSL 

10.0 

MS-DOS 

A 

Linpack 

n/a 

MS-DOS 

C 

MathCAD 

2.0 

MS-DOS 

C 

muMATH-83 

4.12 

MS-DOS 

C 

Solver-2 

— 

MS-DOS 

C 

ODeratina  Svstems 

IBM  PC,  PS/2,  and  compatibles 

IBM  OS/2 

1.0 

n/a 

B 

IBM  PC-DOS 

3.3 

n/a 

B 

Microsoft  MS-DOS  (incl  IBM  PC-DOS) 

3.2 

n/a 

A 

Microsoft  Windows 

2.03 

n/a 

A 
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Software  List  continued 


Package/Compiler 

Version 

Environment 

Microsoft  Windows  386 

2.03 

n/a 

Macintosh  II,  Macintosh  SE, 
and  Macintosh  Plus 

Finder 

6.1 

n/a 

MultiFinder 

6.0.1 

n/a 

System 

6.0.2 

n/a 

Apple  1! 

Apple  II  DOS 

3.3 

n/a 

CP/M 

2.20 

n/a 

ProDos 

1.0 

n/a 

Sound 

Soundwave 

1.0 

Macintosh 

MacRecorder 

1.0 

Macintosh 

SDreadsheet 

APPLEWORKS 

_ 

MS-DOS 

HAL 

1.0 

MS-DOS 

Lotus  1-2-3 

2.01a 

MS-DOS 

Microsoft  Excel 

1.5 

Macintosh 

Microsoft  Excel 

2.0 

MS-DOS 

Multiplan 

1.5 

Macintosh 

Statistical 

BASS 

88.10 

MS-DOS 

MACSPIN 

1.5 

Macintosh 

Minitab 

82.1.1 

MS-DOS 

PowerStat 

1.04 

MS-DOS 

SAS/PC 

6.03 

MS-DOS 

SPSS/PC+ 

3.0 

MS-DOS 

STATPRO 

2.0c 

MS-DOS 

STATWORKS 

1.2 

Macintosh 

SYSTAT 

3.2 

Macintosh 

SYSTAT 

3.2 

MS-DOS 

Word  Processina 

Guide 

2.0 

MS-DOS 

FinalWord  II 

2.0 

MS-DOS 

MacWrite 

5.01 

Macintosh 

Manuscript 

1.0 

MS-DOS 

Microsoft  Word 

3.01 

Macintosh 

Microsoft  Word 

4.0 

MS-DOS 

Nota  Bene 

3.0 

MS-DOS 

Nota  Bene  SLS 

3.0 

MS-DOS 

PC-TeX 

2.1 

MS-DOS 

Sprint 

1.0 

MS-DOS 

T3 

— 

MS-DOS 

Volkswriter  Scientific 

— 

MS-DOS 

WordPerfect 

4.2  &  5.0 

MS-DOS 

WordPerfect 

1.0 

Macintosh 

WordPerfect  Library 

2.0 

MS-DOS 

WordStar 

3.3 

MS-DOS 

Utilities 

Apple  Turnover 

_ 

MS-DOS 

FASTBACK 

— 

MS-DOS 

Norton  Utilities 

4.0 

MS-DOS 

Copy  II  Disk 

7.1 

Macintosh 

Mace  Utilities 

— 

MS-DOS 

MacZap 

5.1 

Macintosh 

Sidekick 

— 

MS-DOS 

SuperKey 

— 

MS-DOS 

TURBO  Lightning 

— 

MS-DOS 

XenoDisk 

1.41 

MS-DOS 

Support 

C 
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Software  List  continued 


msai 


l|||||g 

LWTTT 


EEBpBQ 


WfieSmfflhfm 


il  yl 


■ 

W0t 

1  @ 
m 

m 

IP^lfP 

Sstspil 

: '  * *'  ■ 

111 

lillllllill  n 

t  K.rlMl 

$gf 

.■  ■;:; 


Tv:-: 


Mmm 

fin 


Package/Compiler  System  Support  Version 


Communications 


Kermit 

VM/CMS 

A 

— 

Kermit 

UNIX 

B 

4C(058) 

FTS 

VM/CMS 

A 

— 

MAIL/MAILBOOK 

VM/CMS 

A 

86.359 

MICROLASER 

VM/CMS 

A 

___ 

macget/macput 

UNIX 

C 

— 

netcopy,  netexec,  to  (NetNorth  Tools) 

UNIX 

B 

— 

xmodem 

UNIX 

C 

— 

ftp, rsh.rlogin, telnet, rep 

(Access  via  TCP/IP  to  most  of  the  networked 
machines  on  all  three  campuses)  UNIX 

B 

rn/Pnews 

UNIX 

B 

mail,  mh,  Mail 

UNIX 

- 

— 

Graohics 

PLOTBASIC  (FORTRAN) 

VM/CMS 

C 

--- 

SAS/GRAPH 

VM/CMS 

A 

5.16,  5.18 

Lanouaaes 

ASSEMBLER(F) 

VM/CMS 

C 

--- 

Concurrent  Euclid 

VM/CMS 

C 

1.9 

FORTUTILS 

VM/CMS 

A 

2.2 

PL/I  OPT  Compiler 

VM/CMS 

B 

1.5.1 

REXX 

VM/CMS 

A 

— 

SNOBOL  4 

VM/CMS 

C 

3.5 

Turing 

VM/CMS 

C 

— 

VS  FORTRAN 

VM/CMS 

A 

1.4.1 

VS  Pascal 

VM/CMS 

C 

2.2 

Waterloo  C 

VM/CMS 

C 

1.3 

WATFIV 

VM/CMS 

C 

V2L0 

WATFQR-77 

VM/CMS 

A 

1.3 

cc 

UNIX 

A 

— 

f77 

UNIX 

C 

— 

ratfor 

UNIX 

C 

BSD  std. 

ttc 

UNIX 

C 

— 

pc 

UNIX 

C 

BSD  std. 

yacc 

UNIX 

C 

— 

awk 

UNIX 

C 

— 

adb.dbx 

UNIX 

C 

BSD  std. 

Numerical 

IMSL 

VM/CMS 

A 

9.2,10.0 

LINPACK 

VM/CMS 

C 

— 

NAg 

VM/CMS 

A 

Mark  1 1 

Statistical 

BMDP 

VM/CMS 

A  Level  85,  Level  87 

Minitab 

VM/CMS 

B 

5.1 

NAg 

VM/CMS 

A 

Mark  1 1 

NTSYS 

VM/CMS 

C 

1987 

SAS 

VM/CMS 

A 

5.18 

SPSS* 

VM/CMS 

A 

2.2 
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Software  List  continued 


Package/Compiler  System  Support  Version 


Text  Processing 


SCRIBE 

VM/CMS 

C 

4(1400)-1 

Waterloo  SCRIPT 

VM/CMS 

B 

86.1 

XEDIT 

VM/CMS 

A 

— 

8700  Pseudotypesetting 

VM/CMS 

C 

n/a 

MICROLASER 

VM/CMS 

A 

— 

ed 

UNIX 

A 

— 

vi 

UNIX 

C 

— 

cmacs 

UNIX 

C 

— 

spell 

UNIX 

C 

— 

diction/explain 

UNIX 

C 

— 

eqn 

UNIX 

B 

— 

tbl 

UNIX 

B 

— 

pic 

UNIX 

C 

— 

troff 

UNIX 

B 

— 

nroff 

UNIX 

B 

— 

TeX 

UNIX 

C 

— 

Utilities 


FORTUTILS 

VM/CMS 

A 

2.2 

TPRINT 

VM/CMS 

C 

... 

crypt 

UNIX 

A 

BSD  std. 

compress 

UNIX 

C 

BSD  std. 

csh 

UNIX 

B 

BSD  std. 

diff 

UNIX 

A 

BSD  std. 

grep 

UNIX 

A 

BSD  std. 

ipr 

UNIX 

B 

— 

learn 

UNIX 

C 

BSD  std. 

patch 

UNIX 

C 

... 

sed 

UNIX 

A 

BSD  std. 

sort 

UNIX 

A 

BSD  std. 

sh 

UNIX 

A 

BSD  std. 

tar 

UNIX 

A 

BSD  std. 

uniq 

UNIX 

A 

BSD  std. 
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